Re: [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