Stephen Smalley wrote:
On Fri, 2006-06-02 at 09:49 -0500, Darrel Goeddel wrote:
Here's an attempt using the above approach. What does everyone think? The
only issue I can see is that there may be a possibility of getting some
incorrect audit information if many queued netlink messages are processed
at the same time. The AVC message will include information about "current",
which may not be the sending process. Stephen suggested that the AVC message
could be modified to include the pid from the netlink message instead of
information about current. That would lead to an AVC message stating pid=XXX,
while the syscall message would state pid=YYY. Anyone see a way to get correct
information, or at least suppress possibly incorrect information.
Note that this could involve more than just the pid; it could be any of
the information in the NETLINK_CB or even the NETLINK_CREDS, so it could
also include loginuid and possibly uid info. You can propagate that
data to avc_audit by extending the avc audit data structure, and either
have it log it instead of the current task info or have it log it as
supplemental data in addition to the current task info. You could
further propagate it to syscall audit by setting those values in the
audit context from the netlink information, but it isn't clear that is
what you want and I don't think that gives you the full task information
that is presently logged by audit_log_exit.
The other approach is to move all checking to send time, including
audit_netlink_ok and equivalent checking by other netlink handlers,
using a callback mechanism as proposed in patches by Chris Wright a long
time ago. I'm not sure what happened with those. Then the current task
info is valid for checking and for auditing
Looks like they just died...
http://marc.theaimsgroup.com/?l=linux-netdev&m=110819902809549&w=2
http://marc.theaimsgroup.com/?l=linux-netdev&m=110819906824642&w=2
http://marc.theaimsgroup.com/?l=linux-netdev&m=110819919430147&w=2
http://marc.theaimsgroup.com/?l=linux-netdev&m=110819926630794&w=2
Seems like a nice idea (wish it would have been completed and upstreamed...).
I have no idea how this fits into the current state of the kernel or what
may have been missing from the original implementation. My limited knowledge
of netlink puts this approach out of my league for now (would be nice to learn
more about this in the future though). I'd be happy to see this in the future.
I really
like the idea of getting the AVC message because tracking down cases where
SELinux was denying CAP_AUDIT_XXX was a huge pain when userspace was starting to
become audit-aware...
Yes, and the same applies for CAP_NET_ADMIN check by various netlink
handlers - we don't get any audit messages presently since they are
checked at receive time.
This patch encapsulates the usage of eff_cap (in netlink_skb_params) within
the lsm framework by extending security_netlink_recv to include a required
capability parameter and converting all direct usage of eff_caps outside
of the lsm modules to use the interface. It also updates the SELinux
implementation of the security_netlink_send and security_netlink_recv
hooks to take advantage of the sid in the netlink_skb_params struct.
The patch looks sane to me. I'm not as concerned about the audit
confusion because the portions relevant to policy will be correct (i.e.
the SIDs/contexts).
I am also not really concerned about it. Shall we give this a whirl in the
lspp kernel (since its users are currently exercising the problematic code
path) and include push it through the audit git tree if it works nicely?
Note that this would replace the band-aid patch that is currently included
in the lspp kernel. Anyone object (or have a patch using the callback
method)?
--
Darrel
--
redhat-lspp mailing list
[email protected]
https://www.redhat.com/mailman/listinfo/redhat-lspp
