Thread (61 messages) 61 messages, 11 authors, 2019-08-27

Re: [PATCH v2 bpf-next 1/4] bpf: unprivileged BPF access via /dev/bpf

From: Jordan Glover <hidden>
Date: 2019-08-16 09:34:53
Also in: bpf, linux-api, netdev

On Thursday, August 15, 2019 11:08 PM, Alexei Starovoitov [off-list ref] wrote:
On Thu, Aug 15, 2019 at 11:36:43AM -0700, Andy Lutomirski wrote:
quoted
On Thu, Aug 15, 2019 at 10:29 AM Alexei Starovoitov
alexei.starovoitov@gmail.com wrote:
quoted
On Thu, Aug 15, 2019 at 11:24:54AM +0000, Jordan Glover wrote:
quoted
systemd --user processes aren't "less privileged". The are COMPLETELY unprivileged.
Granting them cap_bpf is the same as granting it to every other unprivileged user
process. Also unprivileged user process can start systemd --user process with any
command they like.
systemd itself is trusted. It's the same binary whether it runs as pid=1
or as pid=123. One of the use cases is to make IPAddressDeny= work with --user.
Subset of that feature already works with AmbientCapabilities=CAP_NET_ADMIN.
CAP_BPF is a natural step in the same direction.
I have the feeling that we're somehow speaking different languages.
What, precisely, do you mean when you say "systemd itself is trusted"?
Do you mean "the administrator trusts that the /lib/systemd/systemd
binary is not malicious"? Do you mean "the administrator trusts that
the running systemd process is not malicious"?
please see
https://github.com/systemd/systemd/commit/4c1567f29aeb60a6741874bca8a8e3a0bd69ed01
I'm not advocating for or against this approach.
Call it 'security hole' or 'better security'.
There are two categories of people for any feature like this.
My point that there is a demand to use bpf for non-root and CAP_NET_ADMIN
level of privileges is acceptable.
Another option is to relax all of bpf to CAP_NET_ADMIN instead of CAP_SYS_ADMIN.
But CAP_BPF is clearly better way.
Do you realize it's not possible to grant CAP_NET_ADMIN or any other CAP in
"systemd --user" service? Trying to do so will fail with:
"Failed to apply ambient capabilities (before UID change): Operation not permitted"

I think it's crucial to clear that point to avoid confusion in this discussion
where people are talking about different things.

On the other hand running "systemd --system" service with:

User=nobody
AmbientCapabilities=CAP_NET_ADMIN

is perfectly legit and clears some security concerns as only privileged user
can start such service.

Jordan
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help