Re: Questions and concerns about BPF-selected interpreter

[Alessandro Di Federico <ale@rev.ng>]

On Thu, 23 Jul 2026 15:15:37 +0200
Christian Brauner <brauner@kernel.org> wrote:

> And the deployment data doesn't have to come from android. nixos and
> rev.ng style deployments will generate it.

Unfortunately, we won't be able to adopt these feature if it requires
root.

> Tools you hand to arbitrary end users won't be covered by any
> kernel-side mechanism for years no matter which one wins because most
> user machines run old kernels.

Well, we're here to improve things in the long run and have a new modern
solution to a stack of suboptimal solutions (see below).

> Is the tree immutable? Who may write to it? Which prefixes are
> trusted? The kernel doesn't know any of that. So no amount of
> security consideration produces semantics that are safe to turn on
> for everyone.

Can you elaborate a scenario?
It seems to me that this is not so much different from RPATH+$ORIGIN
for dynamic linking in user space.

> But an old kernel doesn't cleanly refuse such a binary.
> load_elf_binary() simply ignores program header types it doesn't know. A
> binary with PT_INTERP_ORIGIN and no PT_INTERP loads as static and jumps
> to an entry point that was never relocated and so crashes instead of
> failing with a clean error.

To clarify, the scenario I have in mind is:

```
./enter-sdk-shell
./bin/myprogram
```

`myprogram` has both PT_INTERP_ORIGIN (relative) and PT_INTERP
(absolute /ld.so).

`enter-sdk-shell` detects the features available:

1. If `PT_INTERP_ORIGIN` is supported, just go.

2. If you have user namespaces available, create a new mount namespace
   and put /ld.so there, then go.

3. If everything else fails, ptrace all the things.

Ideally, with time, we'll be able to use just 1).

Note that 2) is not ideal, you basically need to:

```
mkdir ~/fake-root
for X in /*; do
  mount -o bind "$X" ~/fake-root/$(basename "$X")
done

mount -o bind ~/ld.so ~/fake-root/ld.so
userns-chroot ~/fake-root
```

If, for some reason, someone does `mkdir /new-dir` outside of the
chroot, `new-dir` won't be visible from the inside.

This is not a proper solution, it's an hack due to the lack of
something like `$ORIGIN`.

Also, the fact that AppArmor restricts user namespace to trusted
programs is a problem for me as someone distributing software but, from
a security perspective, I understand that. AFAIK many LPE exploits have
a critical path through user namespaces.

$ORIGIN in PT_INTERP would have an indirect side-effect of reducing the
use case for user namespaces.

> Where I remain firm is the split. The header names the intent and the
> handler implements the semantics. If deployments later show that one
> specific resolution policy is stable and safe, graduating that subset
> into the kernel is a discussion we can have.

Can you elaborate a scenario emerging from data that would persuade you
in one way and another scenario that would persuade you in the other
way?

AFAIU you would like to have systemd implement in eBPF
`PT_INTERP_ORIGIN`, see if they get exploited and then maybe implement
it with the acquired wisdom from their experience?

It makes sense, but tbh the most likely scenario is just that this
feature will never take off.
Maybe we can just look at what happened to other kernels, like Illumos:

    https://www.illumos.org/issues/6987
    https://engineering.backtrace.io/2016-06-29-exploiting-elf-expansion-variables/

Or even glibc:

    https://seclists.org/fulldisclosure/2010/Oct/257

On Wed, 22 Jul 2026 12:36:55 +0200
Christian Brauner <brauner@kernel.org> wrote:

> A PT_INTERP of $ORIGIN/ld.so isn't absolute and so Linux resolves it
> relative to the caller's working directory. Execute such a
> "relocatable" binary with an attacker-controlled working directory
> and ./$ORIGIN/ld.so is your loader.

For real? A relative path in PT_INTERP is interpreted relative to cwd?
This is the most cursed thing I've heard in a while.
I understand that Linux has strict policy of not breaking user space,
but I would ban this right away.

-- 
Alessandro Di Federico
rev.ng Labs