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 -- 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
