Eric Lee / smarc-ti-linux-kernel

20 Aug, 2014

1 commit

04 Apr, 2014

1 commit

  • a00e76349   netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks ... Browse Code »
    39

    This simple modification allows iptables to work with INPUT chain
    in combination with cgroup module. It could be useful for counting
    ingress traffic per cgroup with nfacct netfilter module. There
    were no problems to count the egress traffic that way formerly.

    It's possible to get classified sk_buff after PREROUTING, due to
    socket lookup being done in early_demux (tcp_v4_early_demux). Also
    it works for udp as well.

    Trivial usage example, assuming we're in the same shell every step
    and we have enough permissions:

    1) Classic net_cls cgroup initialization:

    mkdir /sys/fs/cgroup/net_cls
    mount -t cgroup -o net_cls net_cls /sys/fs/cgroup/net_cls

    2) Set up cgroup for interesting application:

    mkdir /sys/fs/cgroup/net_cls/wget
    echo 1 > /sys/fs/cgroup/net_cls/wget/net_cls.classid
    echo $BASHPID > /sys/fs/cgroup/net_cls/wget/cgroup.procs

    3) Create kernel counters:

    nfacct add wget-cgroup-in
    iptables -A INPUT -m cgroup ! --cgroup 1 -m nfacct --nfacct-name wget-cgroup-in

    nfacct add wget-cgroup-out
    iptables -A OUTPUT -m cgroup ! --cgroup 1 -m nfacct --nfacct-name wget-cgroup-out

    4) Network usage:

    wget https://www.kernel.org/pub/linux/kernel/v3.x/testing/linux-3.14-rc6.tar.xz

    5) Check results:

    nfacct list

    Cgroup approach is being used for the DataUsage (counting & blocking
    traffic) feature for Samsung's modification of the Tizen OS.

    Signed-off-by: Alexey Perevalov
    Acked-by: Daniel Borkmann
    Signed-off-by: Pablo Neira Ayuso

    Alexey Perevalov
     

04 Jan, 2014

1 commit

  • 82a37132f   netfilter: x_tables: lightweight process control group matching ... Browse Code »

    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
    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
    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.pdf

    Signed-off-by: Daniel Borkmann
    Cc: Tejun Heo
    Cc: cgroups@vger.kernel.org
    Acked-by: Li Zefan
    Signed-off-by: Pablo Neira Ayuso

    Daniel Borkmann