On Wednesday, June 08, 2011 12:12:39 PM Mr Dash Four wrote:
Mr Dash Four wrote:
> 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.
It doesn't matter if its private. If its important enough to log to the audit system,
we can't let something like this slide.
> 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.
Doesn't matter. Its the event that we want and all its attributes. If the label is not
correct, how else are we going to know? Do the LSMs generate an audit event saying
they couldn't lookup a label?
> What happens if I make changes to my security policy and then
run
> ausearch/aureport?
Nothing.
> 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?
Yes, we do.
> else
>
> audit_log_format(ab, " osid=%u", skb->secmark);
>
> _All_ audit code records the number on a failed conversion.
I am assuming you haven't read the above. Show me one good reason why I
should alter my patch to include that abomination of yours?
Because _all_ logging of object labels in the audit system do this. You are asking to
add information to the audit system. I am telling you how its done everywhere else so
that you patch is consistent.
-Steve