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  PHC 
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 3 Feb 2017 17:25:07 -0800
From:   Alexei Starovoitov <>
To:     Daniel Borkmann <>
Cc:     Alexei Starovoitov <>,
        "David S . Miller" <>,
        David Ahern <>,
        Tejun Heo <>,
        Andy Lutomirski <>,
        "Eric W . Biederman" <>,
        Thomas Graf <>,
Subject: Re: [PATCH net] bpf: expose netns inode to bpf programs

On Sat, Feb 04, 2017 at 12:42:31AM +0100, Daniel Borkmann wrote:
> On 02/04/2017 12:06 AM, Alexei Starovoitov wrote:
> >On Fri, Feb 03, 2017 at 10:56:43PM +0100, Daniel Borkmann wrote:
> >>On 01/26/2017 04:27 AM, Alexei Starovoitov wrote:
> >>>in cases where bpf programs are looking at sockets and packets
> >>>that belong to different netns, it could be useful to read netns inode,
> >>>so that programs can make intelligent decisions.
> >>>For example to disallow raw sockets in all non-init netns the program can do:
> >>>if (sk->type == SOCK_RAW && sk->netns_inum != 0xf0000075)
> >>>   return 0;
> >>>where 0xf0000075 inode comes from /proc/pid/ns/net
> >>>
> >>>Similarly TC cls_bpf/act_bpf and socket filters can do
> >>>if (skb->netns_inum == expected_inode)
> >>>
> >>>The lack of netns awareness was a concern even for socket filters,
> >>>since the application can attach the same bpf program to sockets
> >>>in a different netns. Just like tc cls_bpf program can work in
> >>>different netns as well, so it has to be addressed uniformly
> >>>across all types of bpf programs.
> >>
> >>Sorry for jumping in late, but my question is, isn't this helper
> >>really only relevant for BPF_PROG_TYPE_CGROUP_* typed programs?
> >>Thus other prog types making use of bpf_convert_ctx_access()
> >>should probably reject that in .is_valid_access() callback?
> >>
> >>Reason why I'm asking is that for sockets or tc progs, you
> >>already have a netns context where you're attached to, and f.e.
> >>skbs leaving that netns context will be orphaned. Thus, why
> >>would tc or sock filter tailor a program with such a check,
> >>if it can only match/mismatch its own netns inum eventually?
> >
> >Please see the example I provided earlier.
> That example for both socket filter and tc progs specifically
> wasn't quite clear to me, hence my question wrt why it's right
> now a "concern" for these ones. (Again, clear to me for cgroups
> progs.)
> >We can have the same cls_bpf attached to all netns-es.
> >Same for socket filters and everything else.
> So use-case would be that someone wants to attach the very same
> prog via tc to various netdevs sitting in different netns, and
> that prog looks up a map, controlled by initns, with skb->netns_inum
> as key and the resulting value could contain allowed feature bits
> for that specific netns prog the skbs goes through? That would be
> a feature, not "concern", no? At the same time, it's up to the
> user or mgmt app what gets loaded so f.e. it might just as well
> tailor/optimize the progs individually for the devs sitting in
> netns-es to avoid such map lookup.

yes. It's partially feature and partially bugfix.
Just sent a new patch and tried to explain that bit in commit log.

Powered by blists - more mailing lists