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.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
