Re: 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity

On Thu, Oct 07, 2004 at 09:56:07AM -0400, Stephen Smalley wrote:

On Thu, 2004-10-07 at 01:42, Valdis.Kletnieks@vt.edu wrote:

quoted

audit(1097111349.727:0): avc:  denied  { tcp_recv } for  pid=2 comm=ksoftirqd/0 saddr=127.0.0.1 src=25 daddr=127.0.0.1 dest=59639 netif=lo scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:netif_lo_t tclass=netif
audit(1097111349.754:0): avc:  denied  { tcp_recv } for  pid=2 comm=ksoftirqd/0 saddr=127.0.0.1 src=25 daddr=127.0.0.1 dest=59639 netif=lo scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:node_lo_t tclass=node
audit(1097111349.782:0): avc:  denied  { recv_msg } for  pid=2 comm=ksoftirqd/0 saddr=127.0.0.1 src=25 daddr=127.0.0.1 dest=59639 netif=lo scontext=system_u:system_r:fsdaemon_t tcontext=system_u:object_r:smtp_port_t tclass=tcp_socket

At least for the recv_msg error, I *think* the message is generated because
when we get into net/socket.c, we call security_socket_recvmsg() in
__recv_msg() - and (possibly only when we have the VP patch applied?) at that
point we're in a softirqd context rather than the context of the process that
will finally receive the packet, so the SELinux code ends up checking the wrong

Valdis,

These permission checks are based on the receiving socket security
context, not any process security context, and are performed by the
sock_rcv_skb hook when mediating packet receipt on a socket.  The
auxiliary pid and comm or exe information is meaningless for such
checks.  avc_audit could possibly be modified to check whether we are in
softirq and omit them in those cases from the audit messages.  

This has
been discussed previously on the selinux mailing list, please see the
archives.

 an alternative possible solution is to get the packet _out_ from
 the interrupt context and have the aux pid comm exe information added.

 as i understand it "a" possible way to do that would be to have a
 userspace ip_queue which simply marks the packet as "seen it" and then
 does "now please reprocess it".

 by the time that packets get to ip_queue in userspace, they will have
 had their aix pid comm exe info added (and the file sock stuff).

 alternatively, someone could spend a lot of their time doing exactly
 the same thing in kernel-space.

 l.