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

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

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1d949c6b-43cc-f5d0-8448-b9f2f5a00c88@windriver.com>
Date:   Thu, 26 Jan 2017 14:00:55 +0800
From:   Ying Xue <ying.xue@...driver.com>
To:     <ying.xue@...driver.com>
CC:     Daniel Borkmann <daniel@...earbox.net>,
        David Ahern <dsa@...ulusnetworks.com>,
        Tejun Heo <tj@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        Thomas Graf <tgraf@...g.ch>, <netdev@...r.kernel.org>
Subject: Re: [PATCH net] bpf: expose netns inode to bpf programs

tetst teste tetet tetest tetetttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttttt

On 01/26/2017 01:46 PM, Eric W. Biederman wrote:
> Alexei Starovoitov <ast@...com> writes:
> 
>> 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)
> 
> Nacked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
> 
> Particularly you need to compare more than the inode number.
> Further I have never guaranteed there will be exactly one inode
> per network namespace, just that if the device number and the inode
> number pair match they are the same.
> 
> Beyond that the entire concept is complete rubbish.
> 
> The only sane thing is to interpret whatever your bpf program in the
> context of the program which installs it.
> 
> If you can't do that you have a very broken piece of userspace
> interface.  Which appears to be the case here.
> 
> Eric
>