netdev - Re: Permissions for eBPF objects

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: <CAMOXUJkQ-Wh==9nzgx3Sq4RUEBK5ArHk4b=AL0N65L9g6cAqcg@mail.gmail.com>
Date:   Fri, 25 Aug 2017 12:52:02 -0700
From:   Chenbo Feng <fengc@...gle.com>
To:     Jeffrey Vander Stoep <jeffv@...gle.com>
Cc:     Stephen Smalley <sds@...ho.nsa.gov>, netdev@...r.kernel.org,
        SELinux <Selinux@...ho.nsa.gov>
Subject: Re: Permissions for eBPF objects

On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@...gle.com> wrote:
> On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@...ho.nsa.gov> wrote:
>> On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
>> wrote:
>>> I’d like to get your thoughts on adding LSM permission checks on BPF
>>> objects.
>>>
>>> By default, the ability to create and use eBPF maps/programs requires
>>> CAP_SYS_ADMIN [1]. Alternatively, all processes can be granted access
>>> to bpf() functions. This seems like poor granularity. [2]
>>>
>>> Like files and sockets, eBPF maps and programs can be passed between
>>> processes by FD and have a number of functions that map cleanly to
>>> permissions.
>>>
>>> Let me know what you think. Are there simpler alternative approaches
>>> that we haven’t considered?
>>
>> Is it possible to create the map/program in one process (with
>> CAP_SYS_ADMIN), pass the resulting fd to netd, and then use it there
>> (without requiring CAP_SYS_ADMIN in netd itself)?
>
> That might work. Any use of bpf() requires CAP_SYS_ADMIN but netd
> could potentially just apply the prog_fd to a socket:
>
>            setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_BPF,
>                       &prog_fd, sizeof(prog_fd));
>

This specific case might work. But other map and program related operations can
only be done through syscalls. And the syscall can be set to only allow
CAP_SYS_ADMIN processes to use it or open to all processes. So when the
CAP_SYS_ADMIN limitation is enforced, netd will not be able to use any of the
syscalls such as map_look_up, map_update, map_delete even if a
CAP_SYS_ADMIN process passed the fd to it. Here is how this enforcement
implemented:
http://elixir.free-electrons.com/linux/latest/source/kernel/bpf/syscall.c#L1005

>>
>> What level of granularity would be useful?  Would it go beyond just
>> being able to use bpf() at all?
>
> "use" might be sufficient. At least initially.
>
> I could see some others coming in handy. For example, a simple mapping
> of functionality to permissions gives:
> map_create, map_update, map_delete, map_read, prog_load, prog_use.
>
> Of course there's no sense in breaking "use" into multiple permissions if
> we expect the entire set to always be granted together.
>
>>
>>>
>>> Thanks!
>>> Jeff
>>>
>>> [1] http://man7.org/linux/man-pages/man2/bpf.2.html NOTES section
>>> [2] We are considering eBPF for network filtering by netd. Giving
>>> netd
>>> CAP_SYS_ADMIN would considerably increase netd’s privileges.
>>> Alternatively allowing all processes permission to use bpf() goes
>>> against the principle of least privilege exposing a lot of kernel
>>> attack surface to processes that do not actually need it.
>>>