role based audit filtering

Dustin Kirkland dustin.kirkland at us.ibm.com
Tue Dec 6 23:13:48 UTC 2005


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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/linux-audit/attachments/20051206/dea5d797/attachment.sig>


More information about the Linux-audit mailing list