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 permissive
mode 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
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
