* 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity
@ 2004-10-07 5:42 Valdis.Kletnieks
2004-10-07 13:56 ` Stephen Smalley
2004-10-07 18:59 ` Ingo Molnar
0 siblings, 2 replies; 6+ messages in thread
From: Valdis.Kletnieks @ 2004-10-07 5:42 UTC (permalink / raw)
To: linux-kernel, SELinux, Ingo Molnar; +Cc: netdev, linux-net
[-- Attachment #1: Type: text/plain, Size: 1999 bytes --]
(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 #2: Type: application/pgp-signature, Size: 226 bytes --]
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity
2004-10-07 5:42 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity Valdis.Kletnieks
@ 2004-10-07 13:56 ` Stephen Smalley
2004-10-08 9:31 ` Luke Kenneth Casson Leighton
2004-10-07 18:59 ` Ingo Molnar
1 sibling, 1 reply; 6+ messages in thread
From: Stephen Smalley @ 2004-10-07 13:56 UTC (permalink / raw)
To: Valdis Kletnieks; +Cc: lkml, SELinux, Ingo Molnar, netdev, linux-net
On Thu, 2004-10-07 at 01:42, Valdis.Kletnieks@vt.edu 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 <sds@epoch.ncsc.mil>
National Security Agency
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity
2004-10-07 13:56 ` Stephen Smalley
@ 2004-10-08 9:31 ` Luke Kenneth Casson Leighton
2004-10-08 11:18 ` Stephen Smalley
0 siblings, 1 reply; 6+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-10-08 9:31 UTC (permalink / raw)
To: Stephen Smalley
Cc: Valdis Kletnieks, lkml, SELinux, Ingo Molnar, netdev, linux-net
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:
> > 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.
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity
2004-10-08 9:31 ` Luke Kenneth Casson Leighton
@ 2004-10-08 11:18 ` Stephen Smalley
2004-10-08 11:37 ` Luke Kenneth Casson Leighton
0 siblings, 1 reply; 6+ messages in thread
From: Stephen Smalley @ 2004-10-08 11:18 UTC (permalink / raw)
To: Luke Kenneth Casson Leighton
Cc: Valdis Kletnieks, lkml, SELinux, Ingo Molnar, netdev, linux-net
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 <sds@epoch.ncsc.mil>
National Security Agency
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity
2004-10-08 11:18 ` Stephen Smalley
@ 2004-10-08 11:37 ` Luke Kenneth Casson Leighton
0 siblings, 0 replies; 6+ messages in thread
From: Luke Kenneth Casson Leighton @ 2004-10-08 11:37 UTC (permalink / raw)
To: Stephen Smalley
Cc: Valdis Kletnieks, lkml, SELinux, Ingo Molnar, netdev, linux-net
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!
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity
2004-10-07 5:42 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity Valdis.Kletnieks
2004-10-07 13:56 ` Stephen Smalley
@ 2004-10-07 18:59 ` Ingo Molnar
1 sibling, 0 replies; 6+ messages in thread
From: Ingo Molnar @ 2004-10-07 18:59 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: linux-kernel, SELinux, netdev, linux-net
On Thu, 7 Oct 2004 Valdis.Kletnieks@vt.edu 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
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-10-08 11:37 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-10-07 5:42 2.6.9-rc2-mm4-VP-S7 - ksoftirq and selinux oddity Valdis.Kletnieks
2004-10-07 13:56 ` Stephen Smalley
2004-10-08 9:31 ` Luke Kenneth Casson Leighton
2004-10-08 11:18 ` Stephen Smalley
2004-10-08 11:37 ` Luke Kenneth Casson Leighton
2004-10-07 18:59 ` Ingo Molnar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).