James Morris wrote:
On Thu, 22 Nov 2007, Tetsuo Handa wrote:
This patch allows LSM modules filter incoming connections/datagrams
based on the process's security context who is attempting to pick up.
There are already hooks to filter incoming connections/datagrams
based on the socket's security context, but these hooks are not
applicable when one wants to do TCP Wrapper-like filtering
(e.g. App1 is permitted to accept TCP connections from 192.168.0.0/16).
This functionality looks like it could be useful in that we currently have
no direct security mapping from incoming packet to user process, but only
to the receiving socket, as you mention. For SELinux, it may help us
simplify/clarify policy.
It's also been long-desired for netfilter/iptables, to allow ipt_owner to
work cleanly for incoming packets.
So, this probably needs to be implemented in a way which works for both LSM
and netfilter. There have been several discussions on the issue from the
netfilter side, although I don't know what the latest status of that is
(I've expanded the cc list to hopefully get some more feedback).
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.
I actually like Samir Bellabes' approach, which doesn't suffer from
these problems IIRC.
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.
-
To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
