[PATCH 1/2] SELinux Context Label based audit filtering

[Stephen Smalley]

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