Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

procfs: workarounds for AppArmor design flaw

Aperta
  • Qualcosa non va?
#296 4 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
25/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Ferma
Stack tecnologico
linux, rust
Ambito
operating-systems, security

Direzione di ricerca

Start by reading the detached procfs mount discussion and the linked AppArmor workaround in /etc/apparmor.d/abstractions/lxc/container-base; the issue explains how path based AppArmor rules misidentify paths on detached mounts. The issue does not specify a change to make or tests to run, and notes that a possible runc workaround could cause mount lifetime problems, so the desired outcome needs to be established before implementation.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

api/procfs bug linux/upstream

Okay, I've figured it out. This is really dumb. tl;dr: This is really an AppArmor bug (or even a design flaw if you prefer).

For context, the file we are trying to write to is /proc/sys/net/ipv4/ip_unprivileged_port_start. @stgraber figured out that the problematic AppArmor rules are the rules they have which block writing to most /sys files. How is it possible that one affects the other?

Well, the problem is that runc now uses a detached mount of procfs to operate on (this avoids mount race attacks). Because detached mounts have not been attached to the filesystem, d_name (the kernel's facility for generating names for dentries) just generates a name that looks like /foo if you try to open a file foo inside the detached procfs mount. AFAICS this is what AppArmor uses to determine what file you are trying to write to (because AppArmor is path-based, and d_name is the only way to get pathnames from dentries).

This means that when we try to write to /proc/sys/net/ipv4/ip_unprivileged_port_start, AppArmor sees this as us trying to write to /sys/net/ipv4/ip_unprivileged_port_start which is forbidden by the /sys denial rules. I have attached a program that can show this behaviour using a detached tmpfs mount, it's very trivial to trigger:

% ./aa-bug &
c1:~ # ./aa-bug &
fd: /proc/2061/fd/5
[1] 2061
c1:~ # mkdir /proc/2061/fd/5/sys
c1:~ # mkdir /proc/2061/fd/5/sys/foo
mkdir: cannot create directory ‘/proc/2061/fd/5/sys/foo’: Permission denied

aa-bug.go.txt

There is a trivial workaround for this particular sysctl:

-  deny /sys/[^fdck]*{,/**} wklx,
+  deny /sys/[^fdckn]*{,/**} wklx,

(In /etc/apparmor.d/abstractions/lxc/container-base.)

But this doesn't help in the general case for all sysctls. @stgraber has just submitted https://github.com/lxc/incus/pull/2624 which just removes these rules entirely. I think AppArmor should not do this, because it's incredibly broken (literally any detached mount could match against a rule by accident), but this is unfortunately how AppArmor's design works.

From runc's side, we could in theory use this to our advantage -- if we created a tmpfs with a subpath like .go-away-apparmor and then attached our procfs mount to that path, we might be able to subvert AppArmor. However, this has a risk of causing lifetime issues that would require a rework of how we do lookups -- the tmpfs must not be closed after we attach to it because it will lazy-unmount the procfs...

Originally posted by @cyphar in #12484

Lingua principale
Rust
Stelle
146
Fork
12
Merge medio
1g 16h
PR unite (30g)
20

Preparare l'ambiente

  • Include un Dockerfile o un file Docker Compose
  • Nessun modello di pull request
  • Nessuna guida per i contributori

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di cyphar/libpathrs

Tutte le issue di cyphar/libpathrs

Issue simili

Altre issue su Rust

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.