lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Mon, 19 Dec 2016 18:44:10 -0700 From: David Ahern <dsahern@...il.com> To: Andy Lutomirski <luto@...capital.net>, Alexei Starovoitov <alexei.starovoitov@...il.com> Cc: Andy Lutomirski <luto@...nel.org>, Daniel Mack <daniel@...que.org>, Mickaël Salaün <mic@...ikod.net>, Kees Cook <keescook@...omium.org>, Jann Horn <jann@...jh.net>, Tejun Heo <tj@...nel.org>, "David S. Miller" <davem@...emloft.net>, Thomas Graf <tgraf@...g.ch>, Michael Kerrisk <mtk.manpages@...il.com>, Peter Zijlstra <peterz@...radead.org>, Linux API <linux-api@...r.kernel.org>, "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>, Network Development <netdev@...r.kernel.org> Subject: Re: Potential issues (security and otherwise) with the current cgroup-bpf API On 12/19/16 5:25 PM, Andy Lutomirski wrote: > net.socket_create_filter = "none": no filter > net.socket_create_filter = "bpf:baadf00d": bpf filter > net.socket_create_filter = "disallow": no sockets created period > net.socket_create_filter = "iptables:foobar": some iptables thingy > net.socket_create_filter = "nft:blahblahblah": some nft thingy > net.socket_create_filter = "address_family_list:1,2,3": allow AF 1, 2, and 3 Such a scheme works for the socket create filter b/c it is a very simple use case. It does not work for the ingress and egress which allow generic bpf filters. ... >> you're ignoring use cases I described earlier. >> In vrf case there is only one ifindex it needs to bind to. > > I'm totally lost. Can you explain what this has to do with the cgroup > hierarchy? I think the point is that a group hierarchy makes no sense for the VRF use case. What I put into iproute2 is cgrp2/vrf/NAME where NAME is the vrf name. The filter added to it binds ipv4 and ipv6 sockets to a specific device index. cgrp2/vrf is the "default" vrf and does not have a filter. A user can certainly add another layer cgrp2/vrf/NAME/NAME2 but it provides no value since VRF in a VRF does not make sense. ... >>> I like this last one, but IT'S NOT A POSSIBLE FUTURE EXTENSION. You >>> have to do it now (or disable the feature for 4.10). This is why I'm >>> bringing this whole thing up now. >> >> We don't have to touch user visible api here, so extensions are fine. > > Huh? My example in the original email attaches a program in a > sub-hierarchy. Are you saying that 4.11 could make that example stop > working? Are you suggesting sub-cgroups should not be allowed to override the filter of a parent cgroup?
Powered by blists - more mailing lists