Re: [PATCH net] bpf: expose netns inode to bpf programs

[Daniel Borkmann <daniel@iogearbox.net>]

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.

> All bpf programs are global.

True, but for socket filter and tc they are hooked/attached under
a given netns context.

> They can all share info via maps and so on.

>> When making this effort to lookup and hardcode the dev/inode
>> num into the prog, wouldn't it be easier for these types if
>
> we cannot hardcode dev/inode. They are dynamic and depends
> where program runs.

Was referring to the test from above provided example:

 >>> if (skb->netns_inum == expected_inode)

> I'll send a patch shortly that exposes both.

Thanks,
Daniel