Re: Question about BPF acccess checks

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 8/16/19 12:53 PM, Dominick Grift wrote:
On Fri, Aug 16, 2019 at 12:35:09PM -0400, Stephen Smalley wrote:
On 8/16/19 3:27 AM, Dominick Grift wrote:
As of systemd v243rc1 I have been noticing bpf prog_load and prog_run access checks for systemd --user instances (only if secure boot is disabled)
I suspect that this is for IPAddressAllow/Deny= functionality.
So i tried it out and I was not allowed to use the above due to lack of root-access.

Then i read this:
https://lore.kernel.org/linux-security-module/4F52274A-CD70-4261-A255-2C4A7E818141@xxxxxx/T/#t

My question is: Is it expected that BPF prog_load and prog_run is checked when an *unprivileged* process, i suppose, tries to load and run bpf progs?

Are prog_load and prog_run unprivileged operations?

They can be checked for processes that do not have CAP_SYS_ADMIN if that is
what you are asking.  This can occur either during bpf(2) system call

Yes I suppose that was what I was asking. According to an LWN article today unprivileged bpf is not going to happen.

There was sufficient disagreement in that thread by other kernel developers that you shouldn't assume it.

Thus i dontaudited these two since it does not work presently, and it is not going to work in the future.

https://defensec.nl/gitweb/?p=dssp2.git;a=commitdiff;h=1ef329b09a3bee549cd08640663ba5e8ed9d3f56

That's fine as an interim workaround to avoid noise in your logs but it may in fact be supported some day.


Thanks

processing if unprivileged_bpf_disabled is 0 (for prog_load and/or
prog_run), or upon receiving a bpf prog fd from another process (for
prog_run). It is possible that the specific operation will nonetheless fail
due to a later CAP_SYS_ADMIN check applied for specific kinds of bpf
programs.  So it depends on the specifics.

Android policy appears to have changed over time, with netd originally
allowed both prog_load and prog_run (but not sys_admin), and then later bpf
program loading was migrated into a separate bpfloader process (with
prog_load but not sys_admin) and netd was reduced to prog_run, and still
later sys_admin was added to bpfloader to enable loading bpf programs with
tracepoints. Similarly there has been an evolution in the handling of bpf
maps.





[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux