On Tuesday, June 15, 2021 1:01:18 PM EDT Casey Schaufler wrote:
On 6/14/2021 2:13 PM, Steve Grubb wrote:
> Hello,
>
> On Monday, June 14, 2021 3:34:33 PM EDT Casey Schaufler wrote:
>> I'm looking at the audit userspace implications of adding two
>> new kernel audit records. AUDIT_MAC_TASK_CONTEXTS and
>> AUDIT_MAC_OBJ_CONTEXTS are used when there are multiple security
>> modules with a "security context" active on the system. This
>> design has been discussed here at length. The records will look
>>
>> like:
>> AUDIT_MAC_TASK_CONTEXTS
>> subj_<lsmname>=value
>> subj_<lsmname>=value
>> ...
>>
>> Looking at the audit user-space code I see several things
>> that have me concerned. The first is the use of WITH_APPARMOR.
>> Going forward what behavior would we want if subj_apparmor=something
>> shows up on a system that has not got WITH_APPARMOR defined?
>
> I think it should be ignored.
>
>> The code is inconsistent in that it does not use WITH_SELINUX,
>> but that's hardly a surprise given its origins. There is also no
>> WITH_SMACK, but that's unlikely to be an issue since Smack's use
>> of audit is very much like SELinux's.
>
> We can add those WITH_* if you like.
>
>> The question is what to
>> do about filtering when subj=foo is specified. I suggest that if
>> any of subj_selinux, subj_smack or subj_something is "foo", it is
>> a match.
>
> I think that's how we already treat things. There is a linked list for
> AVC's and we match on any of.
>
>> But the SELinux components of a label (level, user, ...)
>> are also available for filtering. If someone wrote a simple Bell &
>> LaPadula LSM filtering by some of those fields could be useful
>> there, too.
>>
>> I would like guidance on whether I ought to go the route of
>> more extensive use of WITH_APPARMOR (and WITH_SMACK, WITH_MUMBLE)
>> or take the path of greater generalization. Or, whether I should
>> treat each case individually and give it my best whack.
>
> To be honest, I have no idea how well the audit system works with any MAC
> system except SE Linux.
Understood. Part of what I'm looking at is ensuring that as multiple
concurrent LSMs come in that the audit user-space isn't mucked up.
ausearch has these options:
-o,--object <SE Linux Object context>
-se,--context <SE Linux context>
-su,--subject <SE Linux context>
Without multiple LSMs we can easily ignore "SE Linux" in these
options and use whatever kind of "context" is available. If I
have SELinux and AppArmor, the implication is that you can't
search on AppArmor information. Should we be adding
-aa,--apparmorcontext <AppArmor context>
-as,--apparmorsubject <AppArmor subject context>
or should we change -se to look at all "contexts", and change
the description to reflect that? Basicaly, I'm asking whether you'd
rather add options for other LSMs or remove descriptions that
specify SELinux.
I'd say any/all contexts available by default. Then we can maybe make a
restriction to specific LSM's later.
-Steve
> I don't really know if its doing the right thing.
>
> Ausearch and report share a parser. It is time sensitive. I usually test
> it on 4 or 5 Gb of logs. We also have the ausearch-test program which
> can be used to test any changes to the parser.
>
>
http://people.redhat.com/sgrubb/audit/ausearch-test-0.6.tar.gz
>
> Once that is squared away, there is the auparse library. It has a table
> that classifies a field name into what it is for interpretation
> purposes. You will find a #ifdef WITH_APPARMOR. I don't know if that
> table is complete or if it needs to be extended for any other MAC
> system.
>
> That then leads to the auparse normalizer. I don't know if we need to
> make
> any changes there. You can trigger its code with ausearch --format csv or
> -- format text.
>
> Also, we have some size limits in user space. How big can an event record
> be if the file is MAX_PATH name length and it has a space in its name or
> directory and each context is it's maximum size? We may need to think
> about how this might change the whole userspace ecosystem's size
> definition, MAX_AUDIT_MESSAGE_LENGTH, since this is part of the ABI. And
> the kernel also has AUDIT_MESSAGE_TEXT_MAX. What would you get with:
>
> # /usr/sbin/auditctl -m `perl -e 'print "A"x8880'`
>
> And last...what about auditctl? Is the syscall filter going to allow
> filtering on these other subject/object components?
>
> -Steve