On 12/27/2013 04:13 AM, Li Zefan wrote: > On 2013/12/24 1:41, Daniel Borkmann wrote: >> It would be useful e.g. in a server or desktop environment to have >> a facility in the notion of fine-grained "per application" or "per >> application group" firewall policies. Probably, users in the mobile, >> embedded area (e.g. Android based) with different security policy >> requirements for application groups could have great benefit from >> that as well. For example, with a little bit of configuration effort, >> an admin could whitelist well-known applications, and thus block >> otherwise unwanted "hard-to-track" applications like [1] from a >> user's machine. Blocking is just one example, 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. >> >> Implementation of PID-based matching would not be appropriate >> as they frequently change, and child tracking would make that >> even more complex and ugly. Cgroups would be a perfect candidate >> for accomplishing that as they associate a set of tasks with a >> set of parameters for one or more subsystems, in our case the >> netfilter subsystem, which, of course, can be combined with other >> cgroup subsystems into something more complex if needed. >> >> As mentioned, to overcome this constraint, such processes could >> be placed into one or multiple cgroups where different fine-grained >> rules can be defined depending on the application scenario, while >> e.g. everything else that is not part of that could be dropped (or >> vice versa), thus making life harder for unwanted processes to >> communicate to the outside world. So, we make use of cgroups here >> to track jobs and limit their resources in terms of iptables >> policies; in other words, limiting, tracking, etc what they are >> allowed to communicate. >> >> In our case we're working on outgoing traffic based on which local >> socket that originated from. Also, one doesn't even need to have >> an a-prio knowledge of the application internals regarding their >> particular use of ports or protocols. Matching is *extremly* >> lightweight as we just test for the sk_classid marker of sockets, >> originating from net_cls. net_cls and netfilter do not contradict >> each other; in fact, each construct can live as standalone or they >> can be used in combination with each other, which is perfectly fine, >> plus it serves Tejun's requirement to not introduce a new cgroups >> subsystem. Through this, we result in a very minimal and efficient >> module, and don't add anything except netfilter code. >> > > I'd suggest splitting cls_cgroup code into 2 parts. The first part > is to manage cgroupfs and classid, and should be put into net/core/ > and add a new config like NET_CGROUP_CLASSID for it. The second part > is specific cls_cgroup code. Sure, if this is wished, I'd do this as a follow-up as it doesn't affect any of this code in netfilter here. Thanks, Daniel -- 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
