[PATCH 2nd revision] Add SELinux context support to AUDIT target
Mr Dash Four
mr.dash.four at googlemail.com
Mon Jun 6 13:10:48 UTC 2011
> 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.
More information about the Linux-audit
mailing list