• Daniel Borkmann's avatar
    netfilter: x_tables: lightweight process control group matching · 82a37132
    Daniel Borkmann authored
    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.
    
    One possible, minimal usage example (many other iptables options
    can be applied obviously):
    
     1) Configuring cgroups if not already done, e.g.:
    
      mkdir /sys/fs/cgroup/net_cls
      mount -t cgroup -o net_cls net_cls /sys/fs/cgroup/net_cls
      mkdir /sys/fs/cgroup/net_cls/0
      echo 1 > /sys/fs/cgroup/net_cls/0/net_cls.classid
      (resp. a real flow handle id for tc)
    
     2) Configuring netfilter (iptables-nftables), e.g.:
    
      iptables -A OUTPUT -m cgroup ! --cgroup 1 -j DROP
    
     3) Running applications, e.g.:
    
      ping 208.67.222.222  <pid:1799>
      echo 1799 > /sys/fs/cgroup/net_cls/0/tasks
      64 bytes from 208.67.222.222: icmp_seq=44 ttl=49 time=11.9 ms
      [...]
      ping 208.67.220.220  <pid:1804>
      ping: sendmsg: Operation not permitted
      [...]
      echo 1804 > /sys/fs/cgroup/net_cls/0/tasks
      64 bytes from 208.67.220.220: icmp_seq=89 ttl=56 time=19.0 ms
      [...]
    
    Of course, real-world deployments would make use of cgroups user
    space toolsuite, or own custom policy daemons dynamically moving
    applications from/to various cgroups.
    
      [1] http://www.blackhat.com/presentations/bh-europe-06/bh-eu-06-biondi/bh-eu-06-biondi-up.pdfSigned-off-by: default avatarDaniel Borkmann <dborkman@redhat.com>
    Cc: Tejun Heo <tj@kernel.org>
    Cc: cgroups@vger.kernel.org
    Acked-by: default avatarLi Zefan <lizefan@huawei.com>
    Signed-off-by: default avatarPablo Neira Ayuso <pablo@netfilter.org>
    82a37132
Makefile 7.39 KB