Thread (13 messages) 13 messages, 4 authors, 2007-12-03

Re: [PATCH net-2.6.25] Add packet filtering based on process's securitycontext.

From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Date: 2007-12-03 13:17:00
Also in: netfilter-devel

Hello.

Patrick McHardy wrote:
No news on that. I'm also a bit sceptical if adding all this complexity
and overhead would really be worth it (considering only netfilter) just
to use the owner match and UID/GID matching. It wouldn't even be
accurate because there is not 1:1 mapping of sockets and processes.
Considering only LSM, socket_post_accept()/socket_post_recv_datagram() hooks are
not complicated at all.
A socket may be mapped to multiple processes, but at the moment of picking up
(i.e. accept()/recvmsg()), I think it is accurate 1:1 mapping.
I'm more interested in "Who picks this connection/datagram up?" than
"Which socket enqueues this connection/datagram?"
It may be indifferent for netfilter, but it is region of interest for me.
I actually like Samir Bellabes' approach, which doesn't suffer from
these problems IIRC.
Oh, I found him at http://nfws.inl.fr/en/?p=50 . (Sorry, I didn't know.)
He is the person who was discussing with me a few days ago.
quoted
quoted
From memory, one approach under discussion was to add netfilter hooks to 
the transport layer, which could be invoked correctly by each type of 
protocol when the target process is selected.
We can only invoke the hooks after the socket lookup, but we don't
know which process is going to call recvmsg() for that socket.
Right. Thus, I'm proposing LSM hooks at accept()/recvmsg() time.

Regards.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help