3:47 p.m.
On Thu, 2006-02-02 at 15:17 -0500, Stephen Smalley wrote:
On Thu, 2006-02-02 at 13:41 -0600, Dustin Kirkland wrote:
> Kernel audit component
>
> This patch is against David Woodhouse's last update of his audit-2.6 git
> tree, plus a patch submitted by Amy Griffis on 2006-01-17 that adds
> support for strings in audit rules. This patch can be found here:
> https://www.redhat.com/archives/linux-audit/2006-January/msg00064.html
Patch was encoded by your mailer.
That it was. Apparently Evolution automatically encodes messages when
signed with a GPG key. Which means a difficult choice between making
the patch readable and establishing authenticity ;)
> Note that this code actually only provides enough functionality
to
> filter on _task_ labels. I'm looking for input or acknowledgment from
> the SELinux guys (cc'd) on the validity of the approach herein.
> Additionally, I'm open to suggestions on how I might similarly collect
> object and user labels for the same filtering mechanism (if required).
> I hope to easily extend this patch to handle those as well, though I
> wanted to put this much forth immediately to incorporate suggestions.
Object security contexts are already being harvested along the way, e.g.
audit_inode() -> audit_inode_context(), so you already have them
available at the point of filter checking. Other (less expensive
option) for both the object contexts and the task context would be to
instead only harvest the SIDs (via new interfaces) and to provide
interfaces for getting specific fields and compare them rather than
having to allocate memory and generate full contexts each time, as we've
discussed before on the list. That does require changes to the SELinux
module and new interfaces from it, of course.
Let the efficiency games begin...
I'll gladly pursue the less expensive option, though I will require some
guidance from you in implementing these new SELinux exported API's.
In this case, I guess I would like to have SELinux export something like
the following hypothetical function, which takes as input a sid and the
field position, and SELinux returns a char pointer to the requested
string:
char *security_get_field_from_sid(u32 sid, u32 field);
As it seems similar in functionality, should it live somewhere near
security_sid_to_context() in security/selinux/ss/services.c? That
function expects a preallocated string... Should it be possible to
return a const char* from the hypothetical security_get_field_from_sid()
to simplify the caller's mem management? Where's the const string
located in SELinux located that could be so sliced up? I'm really
looking for some pointers here.
Thus, the audit code would first need to call something like:
u32 security_get_sid(???);
What arguments would be required to such a function? Could it be
general purpose enough for inode/ipc/etc objects, as well as tasks?
> Comments appreciated...
> diff --git a/include/linux/audit.h b/include/linux/audit.h
> --- a/include/linux/audit.h
> +++ b/include/linux/audit.h
> @@ -140,6 +140,11 @@
> #define AUDIT_PERS 10
> #define AUDIT_ARCH 11
> #define AUDIT_MSGTYPE 12
> +#define AUDIT_SE_USER 13 /* security label user */
> +#define AUDIT_SE_ROLE 14 /* security label role */
> +#define AUDIT_SE_TYPE 15 /* security label type */
> +#define AUDIT_SE_CAT 16 /* security label category */
> +#define AUDIT_SE_SENS 17 /* security label sensitivity */
There can be two levels in the MLS field (a low and a high), so you have
potentially two sensitivities and two category sets, plus you may want
to match on a particular category in a category set, not the entire
thing. Also, the above doesn't seem very extensible to cope with
potential future extension of the SELinux security context.
Well, the audit rule filter structure needs some unique way to identify
each field, which we're doing with a unique integer per field. Looking
at the lines preceding these new #define's, you'll see the rest of the
fields that we're able to filter upon.
I can easily throw in:
AUDIT_SE_CAT_L
AUDIT_SE_CAT_H
AUDIT_SE_SENS_L
AUDIT_SE_SENS_H
And add those to the switch statement. That can continue on basically
indefinitely. I don't know how much growth you expect in the context
label, but the audit system would have to stay in sync with your
changes.
But if I read you correctly, you'd like to see an entirely different
approach.
I suppose we could set the type of the field to a single AUDIT_SE_LABEL,
and elsewhere in the audit_rule_data structure store the offset (the
element number) of the SELinux label to match. Unfortunately, I'm not
seeing a clean place to drop that offset integer into the structure.
Perhaps in audit_rule_data->fieldflags[i], but I don't really think
that's what that structure member was intended for.
Other suggestions?
> diff --git a/kernel/auditsc.c b/kernel/auditsc.c
> --- a/kernel/auditsc.c
> +++ b/kernel/auditsc.c
> @@ -157,15 +157,23 @@ struct audit_context {
> #endif
> };
>
> +static char *audit_get_task_label(void);
>
> /* Compare a task_struct with an audit_rule. Return 1 on match, 0
> * otherwise. */
> static int audit_filter_rules(struct task_struct *tsk,
> struct audit_krule *rule,
> struct audit_context *ctx,
> - enum audit_state *state)
> + enum audit_state *state,
> + char *label)
> {
> int i, j;
> + char *user, *role, *type, *cat, *sens;
> + user = strsep(&label, ":");
> + role = strsep(&label, ":");
> + type = strsep(&label, ":");
> + cat = strsep(&label, ":");
> + sens = strsep(&label, ":");
Audit code should not be directly parsing SELinux contexts.
You want the SELinux module to perform the splitting, and preferably to
even just give you the field directly as a const char * from SID so that
you never have to allocate and generate the entire context string.
Ok. I think the comments/questions I posted above should address
this...
:-Dustin
4:18 p.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Thursday 02 February 2006 16:47, Dustin Kirkland wrote:
Other (less expensive option) for both the object contexts and the
task
context would be to instead only harvest the SIDs (via new interfaces) and
to provide interfaces for getting specific fields and compare them rather
than having to allocate memory and generate full contexts each time, as
we've discussed before on the list. That does require changes to the
SELinux module and new interfaces from it, of course.
Stephen, It might be better if you make an interface for Dustin and send the
patch. We can then apply it locally for testing.
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -140,6 +140,11 @@
> > #define AUDIT_PERS 10
> > #define AUDIT_ARCH 11
> > #define AUDIT_MSGTYPE 12
> > +#define AUDIT_SE_USER 13 /* security label user */
> > +#define AUDIT_SE_ROLE 14 /* security label role */
> > +#define AUDIT_SE_TYPE 15 /* security label type */
> > +#define AUDIT_SE_CAT 16 /* security label category */
> > +#define AUDIT_SE_SENS 17 /* security label sensitivity */
>
> There can be two levels in the MLS field (a low and a high), so you have
> potentially two sensitivities and two category sets, plus you may want
> to match on a particular category in a category set, not the entire
> thing.
I think we are covered. I mentioned to Dustin that those fields need to be
handled as integers for comparison. We should be able to specify a range for
matching like:
-F "se_sensitivity>=2" -F "se_sensitivity<=9"
> Also, the above doesn't seem very extensible to cope with
> potential future extension of the SELinux security context.
Is there a convention for context parsing? If not, we should probably decide
what it will be or at least how to identify the end of what we know so that
if they get out of sync in the future, it would do the wrong thing.
-Steve
4:22 p.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Thursday 02 February 2006 17:18, Steve Grubb wrote:
I think we are covered. I mentioned to Dustin that those fields need
to be
handled as integers for comparison. We should be able to specify a range
for matching like:
-F "se_sensitivity>=2" -F "se_sensitivity<=9"
Oops sb
-F "se_sensitivity>=s2" -F "se_sensitivity<=s9"
Or whatever the local customizations are:
-F "se_sensitivity>=confidential" -F
"se_sensitivity<=top-secret"
-Steve
8:17 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Thu, 2006-02-02 at 17:18 -0500, Steve Grubb wrote:
I think we are covered. I mentioned to Dustin that those fields need
to be
handled as integers for comparison. We should be able to specify a range for
matching like:
-F "se_sensitivity>=2" -F "se_sensitivity<=9"
This requires that SELinux perform the filter interpretation, as the
context structures and dominance relation are purely internal to it, and
the audit system should not be directly tied to them.
Is there a convention for context parsing? If not, we should probably
decide
what it will be or at least how to identify the end of what we know so that
if they get out of sync in the future, it would do the wrong thing.
The "convention" is that only the SELinux module and the core SELinux
libraries parse them. Everything else has to use an API provided by the
SELinux module (for in-kernel users) or the core SELinux libraries (for
userland).
--
Stephen Smalley
National Security Agency
8:27 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Friday 03 February 2006 09:17, Stephen Smalley wrote:
> -F "se_sensitivity>=2" -F
"se_sensitivity<=9"
This requires that SELinux perform the filter interpretation, as the
context structures and dominance relation are purely internal to it, and
the audit system should not be directly tied to them.
The plan was to call SE linux libraries to interpret custom text (public) to
sensitivity and send the raw sensitivity (s0). As for dominance
calculations...we aren't granting access. If someone say they want s2 and
above, we should be able to see that s3 is greater than s2 and generate an
audit record. If you have an api for comparing s3 and s2, let us know and
we'll use it.
The "convention" is that only the SELinux module and the
core SELinux
libraries parse them. Everything else has to use an API provided by the
SELinux module (for in-kernel users) or the core SELinux libraries (for
userland).
I suppose you are right. I should have mentioned that we have no interest in
parsing the full context. User space was going to take the context parsed by
humans as separate fields. This way it is extensible. If a new extension is
added in the future, we add a new field.
In kernel, Dustin was going to use your api to take sid to individual
components. For string we only need = and !=. For levels and sensitivity, we
were going to need to do a comparison since people could desire auditing
secret and above, but let everything else go.
-Steve
8:46 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 09:27 -0500, Steve Grubb wrote:
On Friday 03 February 2006 09:17, Stephen Smalley wrote:
> > -F "se_sensitivity>=2" -F "se_sensitivity<=9"
>
> This requires that SELinux perform the filter interpretation, as the
> context structures and dominance relation are purely internal to it, and
> the audit system should not be directly tied to them.
The plan was to call SE linux libraries to interpret custom text (public) to
sensitivity and send the raw sensitivity (s0).
Right, libsetrans. But that still leaves you with a string that has no
inherent meaning or ordering.
As for dominance
calculations...we aren't granting access. If someone say they want s2 and
above, we should be able to see that s3 is greater than s2 and generate an
audit record. If you have an api for comparing s3 and s2, let us know and
we'll use it.
Nothing guarantees that s3 dominates s2; s2 _could_ dominate s3
depending on the policy specification. In the SELinux security server,
the relevant functions are mls_level_eq (equivalent), mls_level_dom
(dominates), and mls_level_incomp (incomparable), but they act on the
internal structure representation (integer sensitivities and extensible
bitmap category sets), not the string format. audit system needs to
call a SELinux API if it wants to compare two MLS levels.
I suppose you are right. I should have mentioned that we have no
interest in
parsing the full context. User space was going to take the context parsed by
humans as separate fields. This way it is extensible. If a new extension is
added in the future, we add a new field.
That's fine.
In kernel, Dustin was going to use your api to take sid to individual
components. For string we only need = and !=. For levels and sensitivity, we
were going to need to do a comparison since people could desire auditing
secret and above, but let everything else go.
Ok, so this means that SELinux needs to provide an API for such
comparisons, and likely for precomputing the internal context structure
for a given MLS range provided in an audit rule so that we don't have to
re-do that on each filter evaluation. Then you pass a handle to that
precomputed context and the SID to the comparison API, and it returns
the relation (equivalent, dominates, dominatedby, incomparable).
--
Stephen Smalley
National Security Agency
8:47 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Friday 03 February 2006 09:46, Stephen Smalley wrote:
Ok, so this means that SELinux needs to provide an API for such
comparisons, and likely for precomputing the internal context structure
for a given MLS range provided in an audit rule so that we don't have to
re-do that on each filter evaluation.
What if the filter rule was:
auditctl -a exit,always -S open -F "se_sensitivity>=confidential"
And that is all you have to work with? Are we still OK?
-Steve
9:12 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 09:47 -0500, Steve Grubb wrote:
On Friday 03 February 2006 09:46, Stephen Smalley wrote:
> Ok, so this means that SELinux needs to provide an API for such
> comparisons, and likely for precomputing the internal context structure
> for a given MLS range provided in an audit rule so that we don't have to
> re-do that on each filter evaluation.
What if the filter rule was:
auditctl -a exit,always -S open -F "se_sensitivity>=confidential"
And that is all you have to work with? Are we still OK?
First, you'd need a way to indicate whether you mean the low (also
referred to as current) level or the high (also referred to as clearance
or max) level in the above specification, as each security context has
two levels associated with it (they show up abbreviated as a single
level if they happen to be the same), a low and a high.
Given that distinction, the way I see this as working is as follows:
1) the above auditctl command is invoked by the user,
2) auditctl calls libsetrans to map the string "confidential" to the
string "s1",
3) auditctl constructs a filter rule specifying the above filter,
including the "s1" still as a string, and passes it to the kernel audit
system,
4) the kernel audit system passes the "s1" string to a new in-kernel API
for SELinux that returns a void* handle to a precomputed mls level
structure (likely augmented with policy serial number to detect
invalidation due to policy reload) dynamically allocated at the time the
filter rule is inserted,
5) the kernel audit system saves this handle in its internal form of the
filter rule for later use upon filter evaluation/checking,
6) the kernel audit system harvests SIDs as needed during syscall
processing for the current task and objects referenced during the
syscall and saves them off in audit context,
7) upon filter evaluation/checking, the kernel audit system passes the
void* handle saved in the rule and the desired SID to a new in-kernel
API for SELinux that applies the MLS dominance computation and returns
one of (equivalent, dominates, dominatedby, or incomparable).
8) the audit system checks whether the returned relation matches the one
specified in the filter (here, >= is the same as dominates).
9) If so, the audit system then asks for contexts for the relevant SIDs
and adds them to the audit message. This might be an issue btw as we
might run into an allocation failure at this point.
We would also need a callback registered by the audit system to be
called by SELinux upon policy reload to re-compute all of the
precomputed MLS level structures saved in audit filters against the new
policy.
--
Stephen Smalley
National Security Agency
9:14 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 10:12 -0500, Stephen Smalley wrote:
On Fri, 2006-02-03 at 09:47 -0500, Steve Grubb wrote:
> On Friday 03 February 2006 09:46, Stephen Smalley wrote:
> > Ok, so this means that SELinux needs to provide an API for such
> > comparisons, and likely for precomputing the internal context structure
> > for a given MLS range provided in an audit rule so that we don't have to
> > re-do that on each filter evaluation.
>
> What if the filter rule was:
>
> auditctl -a exit,always -S open -F "se_sensitivity>=confidential"
>
> And that is all you have to work with? Are we still OK?
First, you'd need a way to indicate whether you mean the low (also
referred to as current) level or the high (also referred to as clearance
or max) level in the above specification, as each security context has
two levels associated with it (they show up abbreviated as a single
level if they happen to be the same), a low and a high.
The other missing distinction above is whether you are referring to the
process sensitivity or the sensitivity of one of the objects accessed
during the syscall, e.g. the file context.
--
Stephen Smalley
National Security Agency
9:20 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 10:14 -0500, Stephen Smalley wrote:
On Fri, 2006-02-03 at 10:12 -0500, Stephen Smalley wrote:
> On Fri, 2006-02-03 at 09:47 -0500, Steve Grubb wrote:
> > On Friday 03 February 2006 09:46, Stephen Smalley wrote:
> > > Ok, so this means that SELinux needs to provide an API for such
> > > comparisons, and likely for precomputing the internal context structure
> > > for a given MLS range provided in an audit rule so that we don't have
to
> > > re-do that on each filter evaluation.
> >
> > What if the filter rule was:
> >
> > auditctl -a exit,always -S open -F "se_sensitivity>=confidential"
> >
> > And that is all you have to work with? Are we still OK?
>
> First, you'd need a way to indicate whether you mean the low (also
> referred to as current) level or the high (also referred to as clearance
> or max) level in the above specification, as each security context has
> two levels associated with it (they show up abbreviated as a single
> level if they happen to be the same), a low and a high.
The other missing distinction above is whether you are referring to the
process sensitivity or the sensitivity of one of the objects accessed
during the syscall, e.g. the file context.
And where it becomes even more fun is when multiple objects are accessed
during the syscall, e.g. during path lookup you'll harvest one object
context or SID per path component. So is the above filter supposed to
be applied to just the terminal component or all of them?
--
Stephen Smalley
National Security Agency
9:20 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Friday 03 February 2006 10:20, Stephen Smalley wrote:
So is the above filter supposed to be applied to just the terminal
component or all of them?
I would expect it to be the object that is actually opened rather than any
intermediate path components.
-Steve
9:32 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 10:20 -0500, Steve Grubb wrote:
On Friday 03 February 2006 10:20, Stephen Smalley wrote:
> So is the above filter supposed to be applied to just the terminal
> component or all of them?
I would expect it to be the object that is actually opened rather than any
intermediate path components.
Hmm..well, audit system harvests the information for the inodes as the
lookup proceeds, so it ends up with the information for all of them.
And the last one might not even be the terminal component of the
specified path; it may just be the last one before it hit some error
(like a search denial on a directory component).
--
Stephen Smalley
National Security Agency
9:49 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 10:33 -0500, Stephen Smalley wrote:
On Fri, 2006-02-03 at 10:20 -0500, Steve Grubb wrote:
> On Friday 03 February 2006 10:20, Stephen Smalley wrote:
> > So is the above filter supposed to be applied to just the terminal
> > component or all of them?
>
> I would expect it to be the object that is actually opened rather than any
> intermediate path components.
Hmm..well, audit system harvests the information for the inodes as the
lookup proceeds, so it ends up with the information for all of them.
And the last one might not even be the terminal component of the
specified path; it may just be the last one before it hit some error
(like a search denial on a directory component).
also, you still need to distinguish between filters on process context
and filters on object context at the least.
--
Stephen Smalley
National Security Agency
4:49 p.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
Stephen Smalley wrote: [Fri Feb 03 2006, 10:32:54AM EST]
On Fri, 2006-02-03 at 10:20 -0500, Steve Grubb wrote:
> On Friday 03 February 2006 10:20, Stephen Smalley wrote:
> > So is the above filter supposed to be applied to just the terminal
> > component or all of them?
>
> I would expect it to be the object that is actually opened rather than any
> intermediate path components.
Hmm..well, audit system harvests the information for the inodes as the
lookup proceeds, so it ends up with the information for all of them.
That may be how the audit system used to work, but it doesn't work
quite like that anymore.
Audit typically collects information about the inode which is the
terminal component of the specified path. If the operation involves
adding or removing objects from a directory, information about the
relevant dentry parent inodes is also collected.
At most, audit would collect information about:
1) source inode
2) source inode's parent
3) target inode
4) target inode's parent
And the last one might not even be the terminal component of the
specified path; it may just be the last one before it hit some error
(like a search denial on a directory component).
In the unsuccessful case, the source or target inode may not be
collected, and the parent inode may be indicated as the last path
component accessed, as you said.
Hope this helps,
Amy
11:26 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 10:12 -0500, Stephen Smalley wrote:
9) If so, the audit system then asks for contexts for the relevant
SIDs
and adds them to the audit message. This might be an issue btw as we
might run into an allocation failure at this point.
Actually, this "filtering" isn't determining whether or not the context
is added to the messsage... Rather, it's determining whether or not
audit constructs the audit message at all and passes it to the audit
daemon for publication. Maybe, you realized that already--just
clarifying though.
:-Dustin
10:37 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 09:46 -0500, Stephen Smalley wrote:
On Fri, 2006-02-03 at 09:27 -0500, Steve Grubb wrote:
> On Friday 03 February 2006 09:17, Stephen Smalley wrote:
> > > -F "se_sensitivity>=2" -F "se_sensitivity<=9"
> >
> > This requires that SELinux perform the filter interpretation, as the
> > context structures and dominance relation are purely internal to it, and
> > the audit system should not be directly tied to them.
>
> The plan was to call SE linux libraries to interpret custom text (public) to
> sensitivity and send the raw sensitivity (s0).
Right, libsetrans. But that still leaves you with a string that has no
inherent meaning or ordering.
This is begging for placement in a configuration file that allows custom
defined aliases:
"s0" = "non_confidential"
"s1" = "secret"
"s2" = "mostly_secret"
"s3" = "more_secret_than_that"
"s4" = "top_secret"
"s5" = "cheating_on_a_spouse_secret"
Let those be set in either an SELinux config file, or in an Audit config
file. Let audit userspace interpret these human readable aliases to
SELinux's representation.
:-Dustin
8:13 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Thu, 2006-02-02 at 15:47 -0600, Dustin Kirkland wrote:
Let the efficiency games begin...
I'll gladly pursue the less expensive option, though I will require some
guidance from you in implementing these new SELinux exported API's.
In this case, I guess I would like to have SELinux export something like
the following hypothetical function, which takes as input a sid and the
field position, and SELinux returns a char pointer to the requested
string:
char *security_get_field_from_sid(u32 sid, u32 field);
The public interface could even be along the lines of:
selinux_get_role_from_sid
selinux_get_user_from_sid
selinux_get_type_from_sid
selinux_get_range_from_sid
That is ok; they can be internally implemented via common helper as
appropriate.
It should return const char *, and preferably return it via argument
pointer, returning int as the return value to indicate error status.
As it seems similar in functionality, should it live somewhere near
security_sid_to_context() in security/selinux/ss/services.c?
Yes.
That
function expects a preallocated string...
No, that function internally allocates the string buffer and sets
*scontext to refer to it. But for your purposes, there is no reason to
perform any dynamic allocation or copying; you just lookup the SID in
the sidtab, grab the desired field value, and index into the val_to_name
arrays to obtain the already existing string which you can return as a
const char *. Only complicating case is for the MLS range which is
multi-component.
Should it be possible to
return a const char* from the hypothetical security_get_field_from_sid()
to simplify the caller's mem management? Where's the const string
located in SELinux located that could be so sliced up? I'm really
looking for some pointers here.
You would just return a const char * from the existing val_to_name
tables for user/role/type. They aren't internally const, but the caller
doesn't need to modify the returned string.
Thus, the audit code would first need to call something like:
u32 security_get_sid(???);
int return value, pass sid by argument pointer. You'd have
security_task_getsid, security_inode_getsid, etc.
What arguments would be required to such a function? Could it be
general purpose enough for inode/ipc/etc objects, as well as tasks?
One per object type.
But if I read you correctly, you'd like to see an entirely
different
approach.
I suppose we could set the type of the field to a single AUDIT_SE_LABEL,
and elsewhere in the audit_rule_data structure store the offset (the
element number) of the SELinux label to match. Unfortunately, I'm not
seeing a clean place to drop that offset integer into the structure.
Perhaps in audit_rule_data->fieldflags[i], but I don't really think
that's what that structure member was intended for.
Other suggestions?
For the kernel-userland API, you want something extensible so that we
don't have to revise it if we later add another SELinux context field.
But for the in-kernel APIs, it is ok to be fieldname specific as long as
the audit system is not directly interpreting the context string format
itself.
--
Stephen Smalley
National Security Agency
10:29 a.m.
New subject: [PATCH 1/2] SELinux Context Label based audit filtering
On Fri, 2006-02-03 at 09:13 -0500, Stephen Smalley wrote:
The public interface could even be along the lines of:
selinux_get_role_from_sid
selinux_get_user_from_sid
selinux_get_type_from_sid
selinux_get_range_from_sid
That is ok; they can be internally implemented via common helper as
appropriate.
It should return const char *, and preferably return it via argument
pointer, returning int as the return value to indicate error status.
Stephen-
Is this something that you have time to hack together, or should I start
working on it?
:-Dustin
6840
days inactive
6844
days old
linux-audit@lists.linux-audit.osci.io
17 comments
4 participants
participants (4)
-
Amy Griffis -
Dustin Kirkland -
Stephen Smalley -
Steve Grubb