(linux-net and netdev please cc: on replies - am only on lkml and selinux lists)
Found this in the kernel msgs during system startup.
Behavior has been there at least since rc2-mm3-VP-S6. Am running with
SELinx enabled in permissive mode. I haven't built a rc3-mm2 kernel that I can
test on - rc3-mm2-VP-T1 dies for me with the already-known USB issues, and I haven't
backed that patch out yet (maybe will try that later tonight).
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
credentials. I've not waded through the code enough to figure out exactly
where the two tcp_recv messages are generated, but I suspect the root cause is
the same for all three messages.
The messages are happening when smartd is generating an e-mail alert (the
source of the fsdaemon_t). I'm not sure yet whether it's because sendmail
hasn't started yet, and we're seeing ksoftirqd trying to drive the TCP stack
sending an RST back to the SYN, or if there's something else strange going on.
On Thu, 2004-10-07 at 01:42, [email protected] wrote:
> 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
> credentials. I've not waded through the code enough to figure out exactly
> where the two tcp_recv messages are generated, but I suspect the root cause is
> the same for all three messages.
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.
--
Stephen Smalley <[email protected]>
National Security Agency
On Thu, 7 Oct 2004 [email protected] wrote:
> 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 credentials. I've not waded through the code
> enough to figure out exactly where the two tcp_recv messages are
> generated, but I suspect the root cause is the same for all three
> messages.
that would be a problem in the upstream kernel too - softirq load can
execute in any process context (and in ksoftirqd too).
Ingo
On Thu, Oct 07, 2004 at 09:56:07AM -0400, Stephen Smalley wrote:
> On Thu, 2004-10-07 at 01:42, [email protected] wrote:
> > 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.
On Fri, 2004-10-08 at 05:31, Luke Kenneth Casson Leighton wrote:
> an alternative possible solution is to get the packet _out_ from
> the interrupt context and have the aux pid comm exe information added.
No, the network permission checks are intentionally layered to match the
network protocol implementation. There is a process-to-socket check
performed in process context when the data is received from the socket
by an actual process, but there is also the socket-to-netif/node/port
check performed in softirq context when the packet is received on the
socket from the network.
--
Stephen Smalley <[email protected]>
National Security Agency
On Fri, Oct 08, 2004 at 07:18:42AM -0400, Stephen Smalley wrote:
> On Fri, 2004-10-08 at 05:31, Luke Kenneth Casson Leighton wrote:
> > an alternative possible solution is to get the packet _out_ from
> > the interrupt context and have the aux pid comm exe information added.
>
> No, the network permission checks are intentionally layered to match the
> network protocol implementation. There is a process-to-socket check
> performed in process context when the data is received from the socket
> by an actual process, but there is also the socket-to-netif/node/port
> check performed in softirq context when the packet is received on the
> socket from the network.
ah. oh well!