selinux.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Dominick Grift <dac.override@gmail.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: selinux@vger.kernel.org
Subject: Re: Question about BPF acccess checks
Date: Fri, 16 Aug 2019 18:53:51 +0200	[thread overview]
Message-ID: <20190816165351.GA700733@brutus.lan> (raw)
In-Reply-To: <79283dc7-fcce-259e-e16e-a78eef87256d@tycho.nsa.gov>

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

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@fb.com/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.
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

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.

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8 02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]

  reply	other threads:[~2019-08-16 16:53 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-16  7:27 Question about BPF acccess checks Dominick Grift
2019-08-16 16:35 ` Stephen Smalley
2019-08-16 16:53   ` Dominick Grift [this message]
2019-08-16 17:28     ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20190816165351.GA700733@brutus.lan \
    --to=dac.override@gmail.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).