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. We can have the same cls_bpf attached to all netns-es. Same for socket filters and everything else. All bpf programs are global. 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. I'll send a patch shortly that exposes both.
