Permissions for eBPF objects

Permissions for eBPF objects

[Jeffrey Vander Stoep via Selinux]

[-- Attachment #1: Type: text/plain, Size: 957 bytes --]

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?

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.

[-- Attachment #2: Type: text/html, Size: 1175 bytes --]

Permissions for eBPF objects

[Jeffrey Vander Stoep]

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?

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.

Re: Permissions for eBPF objects

[Jeffrey Vander Stoep via Selinux]

[-- Attachment #1: Type: text/plain, Size: 1207 bytes --]

Disregard this email. Re-sending in plain-text mode to prevent rejection by
netdev list.

On Fri, Aug 25, 2017 at 10:56 AM Jeffrey Vander Stoep <jeffv-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
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?
>
> 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.
>

[-- Attachment #2: Type: text/html, Size: 1660 bytes --]

Re: Permissions for eBPF objects

[Stephen Smalley]

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.
> 

Re: Permissions for eBPF objects

[Jeffrey Vander Stoep]

On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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));

>
> 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.
>>

Re: Permissions for eBPF objects

[Chenbo Feng]

On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
> On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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.
>>>

Re: Permissions for eBPF objects

[Casey Schaufler]

Adding the LSM list to the thread.

On 8/25/2017 11:01 AM, Jeffrey Vander Stoep via Selinux wrote:
> I’d like to get your thoughts on adding LSM permission checks on BPF objects.

Aside from the use of these objects requiring privilege,
what sort of controls do you think might be reasonable?
Who "owns" these objects? Can you have a coherent system
if one entity changes maps and another changes programs?
Why would "finer granularity" be better?

While I understand the issues with CAP_SYS_ADMIN being
uncomfortably general I am not the advocate of fine
grained controls that many of my peers and betters are.
Would the increased complexity add value? How?

> 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]

You could put mode bits on your maps, programs, functions.
Do you otherwise treat these as objects, or are the more
like process state?


> 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?
>
> 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.

Just thinking out loud here, but if there is ownership on your
"objects" (objects have names, owners and access controls)
you could let the owner decide who gets to use them, just like
you do with user-space programs. This is kind of iffy for
programs that execute in the kernel, but you're already putting
a lot of trust in the eBPF implementation.

The big thing you need to do is define a security model, with
a list of subjects, objects and accesses. Once you have that
coming up with a basic access control policy is a matter of
creating something Linux-ish. The security modules will follow
on with their own interpretations of how to make it even better
in due course.

Re: Permissions for eBPF objects

[Daniel Borkmann]

On 08/25/2017 09:52 PM, Chenbo Feng wrote:
> On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
>> On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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));

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
>
>>> 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.
>>>>

Re: Permissions for eBPF objects

[Stephen Smalley]

On Fri, 2017-08-25 at 12:52 -0700, Chenbo Feng via Selinux wrote:
> On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.
> com> wrote:
> > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds-+05T5uksL2rAPFwGQJP7nA@public.gmane.org
> > v> 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

I guess the question is whether netd needs to perform any of those
operations itself, or if all of that can be done by another process and
netd can just receive the fd over a unix socket and attach it.

Not opposed to adding a LSM hook to bpf() and implementing a SELinux
check there, just not 100% sure if you need it.

> 
> > > 
> > > 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.
> > > > 

Re: Permissions for eBPF objects

[Chenbo Feng]

On Fri, Aug 25, 2017 at 1:40 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> On Fri, 2017-08-25 at 12:52 -0700, Chenbo Feng via Selinux wrote:
>> On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.
>> com> wrote:
>> > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.nsa.go
>> > v> 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
>
> I guess the question is whether netd needs to perform any of those
> operations itself, or if all of that can be done by another process and
> netd can just receive the fd over a unix socket and attach it.
>
> Not opposed to adding a LSM hook to bpf() and implementing a SELinux
> check there, just not 100% sure if you need it.
>
I am afraid only attach to socket will not need CAP_SYS_ADMIN if the
sysctl_unprivileged_bpf_disabled is set. But in our current design we might
need to attach a eBPF program to cgroups. Besides, reading and updating
the eBPF maps are also necessary operations that netd need to use. And these
are all unavailable to non-CAP_SYS_ADMIN processes when the sysctl is set.
So I guess we must have unprivileged BPF enabled to let our design work. And
adding lsm hooks to eBPF could make it under better control.

>>
>> > >
>> > > 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.
>> > > >

Re: Permissions for eBPF objects

[Alexei Starovoitov]

On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
> On 08/25/2017 09:52 PM, Chenbo Feng wrote:
> > On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
> > > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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.

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.

Re: Permissions for eBPF objects

[Chenbo Feng]

On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
>> On 08/25/2017 09:52 PM, Chenbo Feng wrote:
>> > On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
>> > > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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.
>
> 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.

Re: Permissions for eBPF objects

[Alexei Starovoitov]

On Mon, Aug 28, 2017 at 05:47:19PM -0700, Chenbo Feng wrote:
> On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
> > On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
> >> On 08/25/2017 09:52 PM, Chenbo Feng wrote:
> >> > On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
> >> > > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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.
> >
> > 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) ?

Re: Permissions for eBPF objects

[Chenbo Feng]

On Mon, Aug 28, 2017 at 6:15 PM, Alexei Starovoitov
<alexei.starovoitov@gmail.com> wrote:
> On Mon, Aug 28, 2017 at 05:47:19PM -0700, Chenbo Feng wrote:
>> On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
>> <alexei.starovoitov@gmail.com> wrote:
>> > On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
>> >> On 08/25/2017 09:52 PM, Chenbo Feng wrote:
>> >> > On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
>> >> > > On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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.
>> >
>> > 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.

Re: Permissions for eBPF objects

[Mickaël Salaün]

[-- Attachment #1.1: Type: text/plain, Size: 2147 bytes --]


On 29/08/2017 03:44, Chenbo Feng wrote:
> On Mon, Aug 28, 2017 at 6:15 PM, Alexei Starovoitov
> <alexei.starovoitov@gmail.com> wrote:
>> On Mon, Aug 28, 2017 at 05:47:19PM -0700, Chenbo Feng wrote:
>>> On Fri, Aug 25, 2017 at 6:03 PM, Alexei Starovoitov
>>> <alexei.starovoitov@gmail.com> wrote:
>>>> On Fri, Aug 25, 2017 at 10:07:27PM +0200, Daniel Borkmann wrote:
>>>>> On 08/25/2017 09:52 PM, Chenbo Feng wrote:
>>>>>> On Fri, Aug 25, 2017 at 12:45 PM, Jeffrey Vander Stoep <jeffv@google.com> wrote:
>>>>>>> On Fri, Aug 25, 2017 at 12:26 PM, Stephen Smalley <sds@tycho.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.
>>>>
>>>> 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.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]