Stephen Smalley wrote:
On Thu, 2006-06-01 at 09:13 -0500, Darrel Goeddel wrote:Stephen Smalley wrote:On Wed, 2006-05-31 at 12:35 -0500, Darrel Goeddel wrote:I think I ran across the problem described in this thread: http://www.redhat.com/archives/linux-audit/2006-May/msg00059.html The process' effective capabilities are always being masked with the allowed vector of the avc decision (for self against the capability security class) in netlink's copy of the process capabilities (eff_cap). The allowed vector takes on a slightly different role when SELinux is not in enforcing mode - it starts to track used-but-not-normally- permitted actions in the allowed vector. That is what is causing the first attempt to fail (the allowed vector has not been "inflated") and the following attempts to succeed (the vector has been inflated in response to its previous use). Does my reasoning (and patch) seem to be on track?Alternative: Since the sending task SID is now saved in the netlink control buffer, we could move the netlink checking entirely to the receive side, and perform a normal avc_has_perm() check, via task_has_capability, with corresponding auditing of netlink denials. Similarly for audit_netlink_ok. We couldn't do that in the past because the sender SID wasn't available to us on the receive side.Good idea - I forgot about the sid being there now. That approach would have the benefit of actually getting the AVC denials for capability checks that occur "over netlink". However, this would involve replacing all of the checks using eff_cap (thankfully not very many) with new lsm hook(s). This also will provide better encapsulation for the capability system. I was hoping that this simple patch would have a shot at making the release of 2.6.17 to at least address the current problem.If we think it is warranted, we can push up the simple patch now and then proceed with the more general fix later. But I wasn't clear that the current behavior is a major problem, as it only affects permissivemode operation.
Now that we actually know what the problem is (and that it is only a permissive mode issue), it does not seem very urgent to me. Others may view this as obstacle, but avoiding permissive mode altogether is an even better fix ;) Anyone *need* this? We could also just carry this as a temporary fix in the lspp kernel until a better fix is available.
I can work up patches that creates the new lsm hook to replace the current instances of cap_raised(eff_cap) and move the SELinux checking into that hook. Would a single security_netlink_capable(struct netlink_skb_params) hook suffice, or would decomposition of the the actual actions be preferred (and acceptable)?Possibly generalize the existing security_netlink_recv() hook to also take a capability to check as an argument, and then pass CAP_NET_ADMIN from the net callers and CAP_AUDIT_xxx from audit_netlink_ok.
I'll look into that. A quick glance seems to indicate that the current hook and the usage of eff_cap are in very different places, but I'm not super familiar with the netlink codepath. -- Darrel