Re: [PATCH 2nd revision] Add SELinux context support to AUDIT target

[Mr Dash Four <mr.dash.four@googlemail.com>]

> Exactly my point. There is no leak if its text or numeric.
>   
No, there is no leak if it is a text, but there *is* a leak if it is a 
numeric. I think I've made that quite clear.

>> As for exposing the (internal) numerical representation of the secctx - this was
>> discussed previously and the approach you are suggesting was dropped. To quote
>> Eric on this very issue "[It] exports the internal secid to userspace.
>> These are dynamic, can change on lsm changes, and have no meaning in
>> userspace. We should instead be sending lsm contexts to userspace
>> instead.".
>>     
>
> Doesn't matter. The requirements of the protection profiles say to log the object's 
> label.
> It does not care if its text or numeric. It also does not say sometimes or only 
> when its convenient. :)
Again, I disagree. Logging the internal numerical representation of 
secctx is, as I have already stated about 3 times by now, exposing 
internal (private-to-the-kernel-only) information to userspace. That 
cannot be allowed.

Besides, this numerical representation isn't reliable - these numbers 
are dynamic and can change - another reason why they should not be 
allowed to be present in the audit log. What happens if I make changes 
to my security policy and then run ausearch/aureport? I am either going 
to see different (wrong!) context reported if ausearch/aureport attempts 
to "convert" those numbers into SELinux context, or, I am going to see 
meaningless numbers. Either way, useless or misleading information is 
going to be reported and we don't want that, do we?

>   Its either important enough to log even if text conversion 
> fails or its not important enough to log at all.
>   
That is exactly what the current patch does - if secctx is present (and 
retrievable) it is logged, if not, then it isn't. Quite simple really.