5:13 p.m.
This question is primarily directed to the SELinux gurus, Stephen
Smalley and James Morris, but I'm open to input from anyone.
I sat down today and took a first stab at (b):
FAU_SEL.1 Selective Audit
The TSF shall be able to include or exclude auditable events from the
set of audited events based on the following attributes:
(a) Object identity, user identity, subject identity, host identity, and
event type
(b) Users belonging to a specified Role and Access types (e.g. delete,
insert) on a particular object
The userspace interface might look something like the following, to
filter out messages related to the sysadmin_r role:
auditctl -a entry,always -S open -F role=sysadmin_r
My questions revolve around translating a role string such as
"sysadmin_r" to something that can be easily matched in the kernel.
- What are going to be the best practices here?
- Is it possible for either userspace, or the kernel upon adding the
rule to translate a valid role to some string based id that can be
compared later?
- And speaking of "later", when is going to be the best time to do this
comparison? I'm thinking perhaps of adding the necessary fields to
struct audit_context such that audit_filter_rules() only another case is
needed to do the comparison and match the role. Is that a good place
for this?
- I would expect to be crucified if I attempted to do strcmp() or
strstr() string comparisons/matches in the kernel at the oft-called
filters, so I'm really hoping to keep this to integer comparisons. For
that, I think I might need an api into SELinux to get some sort of
integer looking value to compare. Am I approaching this correctly?
Probably enough questions for now. Thanks!
:-Dustin
5:54 a.m.
New subject: [redhat-lspp] role based audit filtering
On Tue, 6 Dec 2005, Dustin Kirkland wrote:
- I would expect to be crucified if I attempted to do strcmp() or
strstr() string comparisons/matches in the kernel at the oft-called
filters, so I'm really hoping to keep this to integer comparisons. For
that, I think I might need an api into SELinux to get some sort of
integer looking value to compare. Am I approaching this correctly?
This all seems pretty ugly.
Internally, SELinux uses SIDs (integers) which can be translated to
securirty contexts (strings), from which you can extract the role.
Let's say you then keep a mapping of SIDs to roles (with roles, translated
to your own integer representation), you'd get an expensive hit the first
time this had to be determined, but then it could be reasonably cheap.
We'd also need to handle policy change, probably generating an event (the
infrastructure for this exists already in SELinux) which flushes your
SID/role mappings.
- James
--
James Morris
<jmorris(a)redhat.com>
6:10 a.m.
On Tue, 2005-12-06 at 17:13 -0600, Dustin Kirkland wrote:
The userspace interface might look something like the following, to
filter out messages related to the sysadmin_r role:
auditctl -a entry,always -S open -F role=sysadmin_r
nit: sysadm_r
My questions revolve around translating a role string such as
"sysadmin_r" to something that can be easily matched in the kernel.
- What are going to be the best practices here?
- Is it possible for either userspace, or the kernel upon adding the
rule to translate a valid role to some string based id that can be
compared later?
If you want to map the role to an integer index that can be compared,
you need to do that in the kernel. The SELinux security server does
maintain such indices for the individual context components, but doesn't
presently export them outside of the security server (not even to the
rest of the SELinux module, which only deals with SIDs that are indices
to complete contexts, not individual fields). If the security server
starts exporting those indices to the audit system, then we also need to
deal with consistency there, so a policy reload would have to trigger a
re-mapping of the original role strings to the correct index in the new
policy (and the new policy may no longer define that role at all, at
which point you have to invalidate the entire filter in some way).
- And speaking of "later", when is going to be the best
time to do this
comparison? I'm thinking perhaps of adding the necessary fields to
struct audit_context such that audit_filter_rules() only another case is
needed to do the comparison and match the role. Is that a good place
for this?
- I would expect to be crucified if I attempted to do strcmp() or
strstr() string comparisons/matches in the kernel at the oft-called
filters, so I'm really hoping to keep this to integer comparisons. For
that, I think I might need an api into SELinux to get some sort of
integer looking value to compare. Am I approaching this correctly?
I'm not clear on whether this is a legitimate assumption, especially
given the existing overhead already imposed for syscall auditing. But
let's think about what information we have available at the point of
comparison:
- the SID of the task (within SELinux only, not directly exported to the
audit system), and
- the role information in the audit filter role (either string or
integer index).
The audit system could ask SELinux via a new interface for the role
value (string or index) corresponding to the current task, and compare
that value (string or index) with the one in the filter.
--
Stephen Smalley
National Security Agency
11:40 a.m.
New subject: [redhat-lspp] Re: role based audit filtering
On Wed, 2005-12-07 at 07:10 -0500, Stephen Smalley wrote:
If you want to map the role to an integer index that can be
compared,
you need to do that in the kernel. The SELinux security server does
maintain such indices for the individual context components, but doesn't
presently export them outside of the security server (not even to the
rest of the SELinux module, which only deals with SIDs that are indices
to complete contexts, not individual fields). If the security server
starts exporting those indices to the audit system, then we also need to
deal with consistency there, so a policy reload would have to trigger a
re-mapping of the original role strings to the correct index in the new
policy (and the new policy may no longer define that role at all, at
which point you have to invalidate the entire filter in some way).
...
The audit system could ask SELinux via a new interface for the role
value (string or index) corresponding to the current task, and compare
that value (string or index) with the one in the filter.
Ok, this is good info, Stephen. I'm thinking now that we should
probably design this with flexibility in mind so that any of those
components (user,role,type,sensitivity) could be filtered upon.
Now, these indices of individual components that are not exported...
Can SELinux easily and quickly translate the strings into their indices?
Is it hashed or something? If not, we're right back to the string
matching, just pushing the work deeper into SELinux.
The following is conceptual C code that I'm proposing as a design. This
assumes that SELinux can easily split a full context into its components
(or elements as it's called below), and that SELinux can easily turn
these into their unique indices. If that's not the case, please correct
me and I think I'll have to scrap this and go back to the drawing board.
--
Let's say that SELinux exposes the following function to the audit
subsystem:
extern int security_match_element(const char *haystack_ctx, const char *needle,
const int element) {
if (
security_element_atoi(needle) == security_ctx_element_atoi(haystack_ctx, element)
)
return 1;
return 0;
}
Where:
haystack_ctx is a string that might look something like:
"system_u:object_r:tmp_t:s0"
needle is a string that might look something like: "object_r"
element is an int [0-3] (or a #define constant like SECURITY_ROLE_ELEMENT) that specifies
which component to match: 1
Internal to SELinux, helper functions would exist such that the
appropriate element can be extracted from the string and translated to
an int:
#define SECURITY_USER_ELEMENT 0
#define SECURITY_ROLE_ELEMENT 1
#define SECURITY_TYPE_ELEMENT 2
#define SECURITY_SENS_ELEMENT 3
u32 security_ctx_atoi(const char *ctx, const int i) {
char *a;
switch(i) {
case (SECURITY_USER_ELEMENT):
/* get the user element out of ctx string */
case (SECURITY_ROLE_ELEMENT):
/* get the role element out of ctx string */
case (SECURITY_TYPE_ELEMENT):
/* get the role element out of ctx string */
case (SECURITY_SENS_ELEMENT):
/* get the sensitivity element out of ctx string */
}
return security_element_atoi(a);
}
And a function that can translate the string representation to the int:
u32 security_element_atoi(const char *a) {
/* code here that translates a user, role, type, or sensitivity string to an int */
}
Thoughts?
:-Dustin
11:58 a.m.
New subject: [redhat-lspp] Re: role based audit filtering
On Wed, 2005-12-07 at 11:40 -0600, Dustin Kirkland wrote:
Ok, this is good info, Stephen. I'm thinking now that we should
probably design this with flexibility in mind so that any of those
components (user,role,type,sensitivity) could be filtered upon.
Yes, and you also want to allow this for not only the current task
context but for any inode context (or other object context) collected
during the syscall processing. Which gets more complicated, as in the
object context case, you have already done the work to get the string
representation (at least presently) during the syscall processing.
Right? Whereas for the task, you only generate a context string if you
are logging an audit message (i.e. if audit filters evaluated to true),
so you are just using the SID to get to the index without needing to
deal with a string.
Now, these indices of individual components that are not exported...
Can SELinux easily and quickly translate the strings into their indices?
Is it hashed or something? If not, we're right back to the string
matching, just pushing the work deeper into SELinux.
It doesn't matter for mapping the role string in the filter to an index,
because you only do that when the audit filter is inserted, not upon
each filter evaluation. For the current task SID, where you have to
look up the index on filter evaluation or precache it in some manner and
invalidate it upon task SID changes, it is a hash lookup of the SID to
obtain a context structure (not a string), and then just extract the
index value directly from that structure (no translation required).
Let's say that SELinux exposes the following function to the
audit
subsystem:
extern int security_match_element(const char *haystack_ctx, const char *needle,
const int element) {
if (
security_element_atoi(needle) == security_ctx_element_atoi(haystack_ctx, element)
)
return 1;
return 0;
}
Where:
haystack_ctx is a string that might look something like:
"system_u:object_r:tmp_t:s0"
needle is a string that might look something like: "object_r"
element is an int [0-3] (or a #define constant like SECURITY_ROLE_ELEMENT) that specifies
which component to match: 1
Internal to SELinux, helper functions would exist such that the
appropriate element can be extracted from the string and translated to
an int:
#define SECURITY_USER_ELEMENT 0
#define SECURITY_ROLE_ELEMENT 1
#define SECURITY_TYPE_ELEMENT 2
#define SECURITY_SENS_ELEMENT 3
u32 security_ctx_atoi(const char *ctx, const int i) {
char *a;
switch(i) {
case (SECURITY_USER_ELEMENT):
/* get the user element out of ctx string */
case (SECURITY_ROLE_ELEMENT):
/* get the role element out of ctx string */
case (SECURITY_TYPE_ELEMENT):
/* get the role element out of ctx string */
case (SECURITY_SENS_ELEMENT):
/* get the sensitivity element out of ctx string */
}
return security_element_atoi(a);
}
And a function that can translate the string representation to the int:
u32 security_element_atoi(const char *a) {
/* code here that translates a user, role, type, or sensitivity string to an int */
}
Thoughts?
In the task case, you don't need this approach; you compute the one
index at audit filter insertion time and save it in the filter rule
structure, and you perform a hash table lookup of the task SID at audit
filter evaluation time to obtain the corresponding index for comparison
(or you could precache it upon task creation and revalidate it upon task
SID changes, which would require some kind of callback from SELinux upon
such changes).
For the object case, you have already harvested the object context along
the way, so you do need to split the string and might as well just do a
strcmp at that point, as you won't save anything by looking up the
string to obtain the indices then.
--
Stephen Smalley
National Security Agency
6954
days inactive
6955
days old
linux-audit@lists.linux-audit.osci.io
4 comments
3 participants
participants (3)
-
Dustin Kirkland -
James Morris -
Stephen Smalley