[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: Differentiating audit rules in an LSM stack

On Friday, December 22, 2017 3:01:24 PM EST Casey Schaufler wrote:

> The audit rule field types AUDIT_SUBJ_* and AUDIT_OBJ_* are

> defined generically and used by both SELinux and Smack to identify

> fields that are interesting to them. If SELinux and Smack are running

> concurrently both modules will identify audit rules as theirs if

> either has requested the field. Before I go off and create a clever

> solution I think it wise to ask if anyone has thought about or has

> strong opinions on how best to address this unfortunate situation.


> We know that SELinux and Smack together is not an especially

> interesting configuration. It is, however, a grand test case for

> generality of the solution. Any module that wanted to audit fields

> that are defined generically will have this sort of problem.


I'd suggest adding a "lsm=x" field at the beginning so that anyone parsing it can parse appropriately as it encounters the following fields. This really needs to be known early in the parsing rather than at the end.


But another thing to consider is that auditctl can load rules that match any part of the subject/object label as whole words. Meaning I can write a rule to match the selinux type, role, user or level part of the label. That would then make me wonder if we need to tell the rule engine which lsm provides the representation so that a proper match is done?



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]