From: Stephen Smalley <hidden> Date: 2017-08-25 19:26:39
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)?
What level of granularity would be useful? Would it go beyond just
being able to use bpf() at all?
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.
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
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));
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.
quoted
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.
On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep [off-list ref] wrote:
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
quoted
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
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
quoted
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.
quoted
quoted
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.
From: Daniel Borkmann <daniel@iogearbox.net> Date: 2017-08-25 20:07:31
On 08/25/2017 09:52 PM, Chenbo Feng wrote:
On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep [off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
quoted
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
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));
BPF_PROG_TYPE_SOCKET_FILTER can be loaded as unprivileged (unless you
have the sysctl set that unprivileged BPF load is disabled in general);
verifier enforces more strictly in terms of what is allowed in the BPF
program though (e.g. arithmetic on pointers, helper availability, etc).
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
quoted
quoted
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.
quoted
quoted
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.
On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
On 08/25/2017 09:52 PM, Chenbo Feng wrote:
quoted
On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep [off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
quoted
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
I’d like to get your thoughts on adding LSM permission checks on BPF
objects.
before reinventing the wheel please take a look at landlock work.
Everything that was discussed in this thread is covered by it.
The patches have been in development for more than a year and most of the early
issues have been resolved.
It will be presented again during security summit in LA in September.
On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
[off-list ref] wrote:
On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
quoted
On 08/25/2017 09:52 PM, Chenbo Feng wrote:
quoted
On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep [off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
quoted
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
I’d like to get your thoughts on adding LSM permission checks on BPF
objects.
before reinventing the wheel please take a look at landlock work.
Everything that was discussed in this thread is covered by it.
The patches have been in development for more than a year and most of the early
issues have been resolved.
It will be presented again during security summit in LA in September.
I am not very familiar with landlock lsm, isn't this module also
depend on the lsm hooks to do
the landlock check? If so then adding lsm hooks for eBPF object seems
not conflict with the
work on progress.
On Mon, Aug 28, 2017 at 05:47:19PM -0700, Chenbo Feng wrote:
On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
[off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
quoted
On 08/25/2017 09:52 PM, Chenbo Feng wrote:
quoted
On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep [off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
quoted
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
I’d like to get your thoughts on adding LSM permission checks on BPF
objects.
before reinventing the wheel please take a look at landlock work.
Everything that was discussed in this thread is covered by it.
The patches have been in development for more than a year and most of the early
issues have been resolved.
It will be presented again during security summit in LA in September.
I am not very familiar with landlock lsm, isn't this module also
depend on the lsm hooks to do
the landlock check? If so then adding lsm hooks for eBPF object seems
not conflict with the
work on progress.
I see. I got it the other way around. What lsm checks are you proposing?
and why unprivileged_bpf_disabled is not enough?
you want to allow unpriv only for specific user(s) ?
On Mon, Aug 28, 2017 at 6:15 PM, Alexei Starovoitov
[off-list ref] wrote:
On Mon, Aug 28, 2017 at 05:47:19PM -0700, Chenbo Feng wrote:
quoted
On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
[off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
quoted
On 08/25/2017 09:52 PM, Chenbo Feng wrote:
quoted
On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep [off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
quoted
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
I’d like to get your thoughts on adding LSM permission checks on BPF
objects.
before reinventing the wheel please take a look at landlock work.
Everything that was discussed in this thread is covered by it.
The patches have been in development for more than a year and most of the early
issues have been resolved.
It will be presented again during security summit in LA in September.
I am not very familiar with landlock lsm, isn't this module also
depend on the lsm hooks to do
the landlock check? If so then adding lsm hooks for eBPF object seems
not conflict with the
work on progress.
I see. I got it the other way around. What lsm checks are you proposing?
and why unprivileged_bpf_disabled is not enough?
you want to allow unpriv only for specific user(s) ?
Exactly, the proposal patch I am currently working on will add checks
before map creation,
map read, and map modify, since all these functionalities will be
available to all users when
unprivileged_bpf_disabled is turned off. And eBPF prog_load may also
need a check as well
since loading some types of program is not restricted either.
On Mon, Aug 28, 2017 at 6:15 PM, Alexei Starovoitov
[off-list ref] wrote:
quoted
On Mon, Aug 28, 2017 at 05:47:19PM -0700, Chenbo Feng wrote:
quoted
On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
[off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
quoted
On 08/25/2017 09:52 PM, Chenbo Feng wrote:
quoted
On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep [off-list ref] wrote:
quoted
On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley [off-list ref] wrote:
quoted
On Fri, 2017-08-25 at 11:01 -0700, Jeffrey Vander Stoep via Selinux
wrote:
quoted
I’d like to get your thoughts on adding LSM permission checks on BPF
objects.
before reinventing the wheel please take a look at landlock work.
Everything that was discussed in this thread is covered by it.
The patches have been in development for more than a year and most of the early
issues have been resolved.
It will be presented again during security summit in LA in September.
I am not very familiar with landlock lsm, isn't this module also
depend on the lsm hooks to do
the landlock check? If so then adding lsm hooks for eBPF object seems
not conflict with the
work on progress.
I see. I got it the other way around. What lsm checks are you proposing?
and why unprivileged_bpf_disabled is not enough?
you want to allow unpriv only for specific user(s) ?
Exactly, the proposal patch I am currently working on will add checks
before map creation,
map read, and map modify, since all these functionalities will be
available to all users when
unprivileged_bpf_disabled is turned off. And eBPF prog_load may also
need a check as well
since loading some types of program is not restricted either.
It would be interesting to be able to check a wide range of actions
performed with the BPF syscall: the command and the union bpf_attr
argument. Because it is a multiplexer, that may be challenging, though.