(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.
Attachment:
pgpqhfRzze30C.pgp
Description: PGP signature
