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: <4c761626-b127-4419-55e4-902b03532507@cumulusnetworks.com>
Date:   Tue, 31 Jan 2017 15:11:27 -0700
From:   David Ahern <dsa@...ulusnetworks.com>
To:     Alexei Starovoitov <ast@...com>,
        "David S . Miller" <davem@...emloft.net>
Cc:     Daniel Borkmann <daniel@...earbox.net>, Tejun Heo <tj@...nel.org>,
        Andy Lutomirski <luto@...capital.net>,
        "Eric W . Biederman" <ebiederm@...ssion.com>,
        Thomas Graf <tgraf@...g.ch>, netdev@...r.kernel.org
Subject: Re: [PATCH net] bpf: expose netns inode to bpf programs

On 1/25/17 8:27 PM, 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.
> 
> Signed-off-by: Alexei Starovoitov <ast@...nel.org>
> ---
> with corresponding change in 'ip vrf' that David Ahern is working on,
> this will address 'malfunction' concern that Andy discovered in 'ip vrf',
> hence this fix is needed for 'net'.

FWIW, the iproute2 patch (along with a few other namespace related fixups) can be found here:

    https://github.com/dsahern/iproute2

vrf/ip-vrf branch.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ