On 10/21/2013 05:09 PM, Daniel Wagner wrote:
On 10/19/2013 08:16 AM, Daniel Borkmann wrote:
On 10/19/2013 01:21 AM, Eric W. Biederman wrote:
I am coming to this late. But two concrete suggestions.
1) process groups and sessions don't change as frequently as pids.
2) It is possible to put a set of processes in their own network
namespace and pipe just the packets you want those processes to
use into that network namespace. Using an ingress queueing filter
makes that process very efficient even if you have to filter by port.
Actually in our case we're filtering outgoing traffic, based on which
local socket that originated from; so you wouldn't need all of that
construct. Also, you wouldn't even need to have an a-prio knowledge of
the application internals regarding their use of particular use of ports
or protocols. I don't think that such a setup will have the same
efficiency, ease of use, and power to distinguish the application the
traffic came from in such a lightweight, protocol independent and easy way.
Sorry for beeing late as well (and also stupid question)
Couldn't you use something from the LSM? I mean you allow the
application to create the socket etc and then block later
the traffic originated from that socket. Wouldn't it make
more sense to block early?
I gave one simple example for blocking in the commit message,
that's true, but it is not limited to that, meaning we can have
much different scenarios/policies that netfilter allows us than
just blocking, e.g. fine grained settings where applications are
allowed to connect/send traffic to, application traffic marking/
conntracking, application-specific packet mangling, and so on,
just think of the whole netfilter universe.
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
