netdev - Re: [PATCH net-next v6 0/5] bpf: security: New file mode and LSM hooks for eBPF object permission control

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-Id: <20171018.134729.837318478487425125.davem@davemloft.net>
Date:   Wed, 18 Oct 2017 13:47:29 +0100 (WEST)
From:   David Miller <davem@...emloft.net>
To:     chenbofeng.kernel@...il.com
Cc:     netdev@...r.kernel.org, Selinux@...ho.nsa.gov,
        linux-security-module@...r.kernel.org, jeffv@...gle.com,
        alexei.starovoitov@...il.com, lorenzo@...gle.com,
        daniel@...earbox.net, sds@...ho.nsa.gov, james.l.morris@...cle.com,
        paul@...l-moore.com, fengc@...gle.com
Subject: Re: [PATCH net-next v6 0/5] bpf: security: New file mode and LSM
 hooks for eBPF object permission control

From: Chenbo Feng <chenbofeng.kernel@...il.com>
Date: Mon, 16 Oct 2017 12:11:30 -0700

> Much like files and sockets, eBPF objects are accessed, controlled, and
> shared via a file descriptor (FD). Unlike files and sockets, the
> existing mechanism for eBPF object access control is very limited.
> Currently there are two options for granting accessing to eBPF
> operations: grant access to all processes, or only CAP_SYS_ADMIN
> processes. The CAP_SYS_ADMIN-only mode is not ideal because most users
> do not have this capability and granting a user CAP_SYS_ADMIN grants too
> many other security-sensitive permissions. It also unnecessarily allows
> all CAP_SYS_ADMIN processes access to eBPF functionality. Allowing all
> processes to access to eBPF objects is also undesirable since it has
> potential to allow unprivileged processes to consume kernel memory, and
> opens up attack surface to the kernel.
> 
> Adding LSM hooks maintains the status quo for systems which do not use
> an LSM, preserving compatibility with userspace, while allowing security
> modules to choose how best to handle permissions on eBPF objects. Here
> is a possible use case for the lsm hooks with selinux module:
> 
> The network-control daemon (netd) creates and loads an eBPF object for
> network packet filtering and analysis. It passes the object FD to an
> unprivileged network monitor app (netmonitor), which is not allowed to
> create, modify or load eBPF objects, but is allowed to read the traffic
> stats from the map.
> 
> Selinux could use these hooks to grant the following permissions:
> allow netd self:bpf_map { create read write};
> allow netmonitor netd:fd use;
> allow netmonitor netd:bpf_map read;
> 
> In this patch series, A file mode is added to bpf map to store the
> accessing mode. With this file mode flags, the map can be obtained read
> only, write only or read and write. With the help of this file mode,
> several security hooks can be added to the eBPF syscall implementations
> to do permissions checks. These LSM hooks are mainly focused on checking
> the process privileges before it obtains the fd for a specific bpf
> object. No matter from a file location or from a eBPF id. Besides that,
> a general check hook is also implemented at the start of bpf syscalls so
> that each security module can have their own implementation on the reset
> of bpf object related functionalities.
> 
> In order to store the ownership and security information about eBPF
> maps, a security field pointer is added to the struct bpf_map. And the
> last two patch set are implementation of selinux check on these hooks
> introduced, plus an additional check when eBPF object is passed between
> processes using unix socket as well as binder IPC.

Series applied.