lkml.org 
[lkml]   [2004]   [Oct]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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:

> > 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.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 14:06    [W:0.037 / U:0.204 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site