☰

Können Sie weiterhin auf das aktuelle Verzeichnis (oder Stammverzeichnis) zugreifen, wenn Ihr Benutzer keine Berechtigung für dieses Verzeichnis hat?

tag-icon • tag-icon permissions
Können Sie weiterhin auf das aktuelle Verzeichnis (oder Stammverzeichnis) zugreifen, wenn Ihr Benutzer keine Berechtigung für dieses Verzeichnis hat?

Es ist möglich, dass ein Programm einen offenen Dateideskriptor für eine Datei erbt oder erhält, die es sonst nicht lesen (oder schreiben) dürfte. Beispiel:

(sudo -u nobody echo "hello world") > ~/test-file
(sudo -u nobody cat) < ~/test-file

Frage: Wenn Sie ein aktuelles Verzeichnis (oder Stammverzeichnis) erben, auf das Ihr Benutzer ansonsten keinen Zugriff hätte, dürfen Sie darauf zugreifen?

Antwort1

Der Vergleich mit Datei-Deskriptoren ist höchst irreführend: Das aktuelle und das Stammverzeichnis eines Prozesses sind keine Datei-Deskriptoren oder irgendwelche Zeiger auf eine „offene Dateibeschreibung“ (a struct file), sondern lediglich Zeiger auf Verzeichniseinträge ( struct dentrys).

Der Kernel speichert keine offene Dateibeschreibung mit Bezug auf den Verzeichnis-Inode, auf den entweder das aktuelle Verzeichnis oder das Stammverzeichnis zeigt, und die über einen beliebigen Handle an untergeordnete Prozesse vererbt werden könnte.

Damit sie überhaupt verwendet werden können, müssen das aktuelle Verzeichnis und das Stammverzeichnis wie jede andere Datei über den Pfad geöffnet werden und alle Standardprüfungen werden angewendet.

Das Öffnen einer Datei mit O_PATHgibt nur einen undurchsichtigen Handle zurück und funktioniert mitbeliebigDatei, die nicht normal zum Lesen oder Schreiben geöffnet werden konnte, vorausgesetzt, der Pfad dazu ist zugänglich:

$ perl -e 'sysopen my $fh, "/root", 0, 0 or die "$!"'
Permission denied at -e line 1.
$ perl -e 'sysopen my $fh, "/root", 010000000, 0 or die "$!"' # 010000000 is O_PATH
$

Solch ein undurchsichtiges FD kann nicht als normales FD verwendet werden, nicht einmal von privilegierten Prozessen, und glücklicherweise gibt es keine Möglichkeit, es openat(fd, "", AT_EMPTY_PATH|O_RDWR)mit einer Anweisung dup()in einen regulären Dateideskriptor umzuwandeln ;-)

Übrigens, die Musl-Bibliothekdefiniert O_SEARCHwie O_PATHseit2012.

Antwort2

NEIN.

# sudo -u nobody ls .
ls: cannot access '.': Permission denied

# sudo -u nobody ls -d .
ls: cannot access '.': Permission denied

# chmod o-rwx /chroot
# chroot --userspec=nobody:nobody /chroot
chroot: failed to run command ‘/bin/bash’: Permission denied

Dasselbe gilt auch für den Schreibzugriff auf das aktuelle Verzeichnis (oder Stammverzeichnis). Wenn dies nicht der Fall wäre, vermute ich, dass dies eine Quelle von Sicherheitslücken wäre :-).

Ein ähnliches Verhalten gilt für Dateideskriptoren, die O_PATHunter Linux geöffnet werden.

POSIX (das nicht definiert O_PATH) impliziert, dass openat(fd, path, ...)und ähnliche Funktionen die Berechtigung zum Zugriff auf das geöffnete Verzeichnis erneut prüfen fd.es sei denn fdwurde mit geöffnet O_SEARCH. Linux unterstützt nichtO_SEARCH.

verwandte Informationen