On Thu, Oct 07, 2004 at 09:56:07AM -0400, Stephen Smalley wrote:
> On Thu, 2004-10-07 at 01:42, Valdis.Kletnieks@xxxxxx 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.
|