Re: [PATCH v7] SELinux: Add support for BPF token access control

Paul Moore
2026-01-13T16:52:08Z

On Mon, Jan 12, 2026 at 9:14 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
> On Fri, Jan 9, 2026 at 10:34 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Wed, Dec 10, 2025 at 12:37 PM Daniel Durning
> > <danieldurning.work@gmail.com> wrote:
> > > On Thu, Dec 4, 2025 at 10:12 PM Eric Suen <ericsu@linux.microsoft.com> wrote:
> > > > On 12/4/2025 6:42 PM, Eric Suen wrote:
> > > >
> > > > I need to mention that this patch is based on v6.17. Ran into few
> > > > Hyper-V VM/testing issues with the latest kernel (v6.18) that I have not
> > > > yet been able to resolve. I believe the issues are related to HYPERV
> > > > configs, but troubleshooting will take some time. In the meantime, I
> > > > would like to get this patch reviewed early.
> > > > > BPF token support was introduced to allow a privileged process to delegate
> > > > > limited BPF functionality—such as map creation and program loading—to
> > > > > an unprivileged process:
> > > > > https://lore.kernel.org/linux-security-module/20231130185229.2688956-1-andrii@kernel.org/
> > > > >
> > > > > This patch adds SELinux support for controlling BPF token access. With
> > > > > this change, SELinux policies can now enforce constraints on BPF token
> > > > > usage based on both the delegating (privileged) process and the recipient
> > > > > (unprivileged) process.
> > > > >
> > > > > Supported operations currently include:
> > > > > - map_create
> > > > > - prog_load
> > > > >
> > > > > High-level workflow:
> > > > > 1. An unprivileged process creates a VFS context via `fsopen()` and
> > > > > obtains a file descriptor.
> > > > > 2. This descriptor is passed to a privileged process, which configures
> > > > > BPF token delegation options and mounts a BPF filesystem.
> > > > > 3. SELinux records the `creator_sid` of the privileged process during
> > > > > mount setup.
> > > > > 4. The unprivileged process then uses this BPF fs mount to create a
> > > > > token and attach it to subsequent BPF syscalls.
> > > > > 5. During verification of `map_create` and `prog_load`, SELinux uses
> > > > > `creator_sid` and the current SID to check policy permissions via:
> > > > > avc_has_perm(creator_sid, current_sid, SECCLASS_BPF,
> > > > > BPF__MAP_CREATE, NULL);
> > > > >
> > > > > The implementation introduces two new permissions:
> > > > > - map_create_as
> > > > > - prog_load_as
> > > > >
> > > > > At token creation time, SELinux verifies that the current process has the
> > > > > appropriate `*_as` permission (depending on the `allowed_cmds` value in
> > > > > the bpf_token) to act on behalf of the `creator_sid`.
> > > > >
> > > > > Example SELinux policy:
> > > > > allow test_bpf_t self:bpf {
> > > > > map_create map_read map_write prog_load prog_run
> > > > > map_create_as prog_load_as
> > > > > };
> > > > >
> > > > > Additionally, a new policy capability bpf_token_perms is added to ensure
> > > > > backward compatibility. If disabled, previous behavior ((checks based on
> > > > > current process SID)) is preserved.
> > > > >
> > > > > Signed-off-by: Eric Suen <ericsu@linux.microsoft.com>
> > >
> > > Tested-by: Daniel Durning <danieldurning.work@gmail.com>
> > > Reviewed-by: Daniel Durning <danieldurning.work@gmail.com>
> >
> > Thanks Eric and Daniel! The v7 revision looks pretty good to me, does
> > anyone have any other issues or concerns with this patch?
>
> No concerns but was waiting for a version based on something newer than 6.17.

I did a merge against selinux/dev last week to review it and while
some manual fixups were needed the fuzz wasn't too bad, I've
definitely seen worse. Hearing no concerns, let me give the merged
commit another quick look and assuming all looks good I'll plan to
update selinux/dev later today. I'll send a note once it is upstream
in selinux/dev and folks can double check the merge if they want.

--
paul-moore.com