On Wed, 2005-02-09 at 20:11, Chris Wright wrote:
> * Chris Wright (chrisw@xxxxxxxx) wrote:
> > Hmm, perhaps we could eliminate the whole asynchronous issue by allowing
> > registration of a netlink link specific security handler. Something like:
> > netlink_kernel_create_sec(unit, rx, sec_handler)
> > Then the check would be done before the packet was ever queued. This
> > would eliminate the if (NETLINK_CREDS(skb)->$cred == bad) on receipt
> > side, and push it to sender side. It would also be link specific so
> > audit could do it's audit payload loginuid check here. I think it would
> > also eliminate SELinux's need to tag the packet for later checking on
> > receipt. Thoughts?
> Here's an example of what I mean. It's quite rough, doesn't yet eliminate
> any of the code that it eventually could, and doesn't deal with broadcast.
> I gave it a quick test with audit netlink, and it does what I expect.
Why not just call the security handler from the security_netlink_send()
function, which is already called by netlink_sendmsg()? Note that
SELinux (thanks to work by James Morris a while back) does apply
fine-grained netlink controls using its selinux_netlink_send() hook
function, but the problem with this approach is that it requires
maintaining a netlink message type table within SELinux itself that maps
netlink operations to generic flow operations (read, write), effectively
duplicating state between SELinux and the netlink protocol
implementations. It also isn't necessarily sufficiently granular for
all needs. It would be preferable to have the netlink protocol
implementations to maintain such mappings and just invoke security
modules to check the generic permissions based on its own internal
mapping (same idea applies for ioctls, where the device driver or
filesystem code should handle the mapping to generic permissions and
only invoke the security module to check the generic permission).
Stephen Smalley <sds@xxxxxxxxxxxxxx>
National Security Agency