Zum Heise-Artikel "Fehler im Linux-Kernel" ermöglicht Rechteausweitung

[Cordess]

Evt. könnte man so eine binary mit setuid-bit austricksen... ich vertrau dem Frieden noch nicht ganz, finde aber die Überschrift des Heise-Artikels noch ein wenig zu clickbaitig.

Sehe ich auch so.

Habe es mal auf meinem Raspberry Pi mit Rasbian (basiert auf bullseye) probiert und ein paar Tests versucht:

Code: Alles auswählen

# cat /etc/debian_version 
11.3
# unshare -Unr /bin/bash
# echo $UID
0
# whoami
root
# cd /sbin
# visudo
visudo: /etc/sudo.conf is owned by uid 65534, should be 0
visudo: /etc/sudoers: Keine Berechtigung
# useradd bill
useradd: /etc/passwd konnte nicht gesperrt werden; versuchen Sie es später noch einmal.
# passwd
Geben Sie ein neues Passwort ein: 
Geben Sie das neue Passwort erneut ein: 
passwd: Fehler beim Ändern des Authentifizierungstoken
passwd: Passwort nicht geändert
# rmmod ip_tables
rmmod: ERROR: ../libkmod/libkmod-module.c:799 kmod_module_remove_module() could not remove 'ip_tables': Operation not permitted
rmmod: ERROR: could not remove module ip_tables: Operation not permitted
# modprobe r8712u
modprobe: ERROR: could not insert 'r8712u': Operation not permitted

Und unter meinem Debian auf meinem PC habe ich noch /var/log und systemctl ausprobiert:

Code: Alles auswählen

# cat /var/log/kern.log
cat: kern.log: Keine Berechtigung
# unshare -Unr /bin/bash
# whoami
root
# cat /var/log/kern.log
cat: kern.log: Keine Berechtigung
# systemctl status
Failed to connect to bus: Operation not permitted (consider using --machine=<user>@.host --user to connect to bus of other user)
# sudo systemctl status
sudo: /etc/sudo.conf is owned by uid 65534, should be 0
sudo: /etc/sudo.conf is owned by uid 65534, should be 0
sudo: Fehler in /etc/sudo.conf, Zeile 0, während Plugin »sudoers_policy« geladen wurde
sudo: /usr/lib/sudo/sudoers.so muss Benutzer mit UID 0 gehören
sudo: Schwerwiegender Fehler, Plugins konnten nicht geladen werden

Es wird somit einem zwar eine root Konsole vorgekaukelt, aber faktisch hat man dennoch keine echten root Rechte.
Momentan scheint also noch alles sicher zu sein.

Und ein Installationsskript zu täuschen hat nur einen geringen Nutzen, da man hier auch einfach das Installationsskript ändern könnte und in Verzeichnisse von root Schreiben geht ja, siehe oben, ohnehin nicht.

[DeletedUserReAsG]

Und ein Installationsskript zu täuschen hat nur einen geringen Nutzen, da man hier auch einfach das Installationsskript ändern könnte

Lade dir mal das von mir angeführte Programm und ändere es entsprechend ab. Das erste Problem könnte auftreten, wenn du die 606MB große und zum Teil aus Binärdaten bestehende Datei in einem Editor öffnen willst, und dann wirst finden, dass ein Teil der Abfragen in eben diesem binären Teil ist.

Wenn du das dann geschafft haben solltest, vergleiche den zeitlichen Aufwand mit dem des unshare-Aufrufs. Anschließend versuche zu begründen, warum du den Nutzen immer noch als gering einschätzt.

[Cordess]

Wenn du das dann geschafft haben solltest, vergleiche den zeitlichen Aufwand mit dem des unshare-Aufrufs. Anschließend versuche zu begründen, warum du den Nutzen immer noch als gering einschätzt.

Die meisten Intstaller lassen es auch zu, dass man das Programm irgendwo im Benutzerverzeichnis installiert, root Rechte werden nur für eine systemweite Installation benötigt und wenn du das benötigst, dann brauchst du ohnehin einen echten root Zugriff.

[DeletedUserReAsG]

Die meisten Intstaller lassen es auch zu, dass man das Programm irgendwo im Benutzerverzeichnis installiert

Was nutzen mir die meisten Installer, wenn es bei dem konkret benannten Installer nicht möglich ist? Es ist nicht so, dass ich das aus der Luft gegriffen hätte, um auch mal was schreiben zu können.

Man kann bei diesem Installer zwar ein abweichendes Installationsverzeichnis angeben, dennoch wird versucht, eine udev-Regel unter /etc, sowie eine .desktop-Datei und diverse Icons irgendwo unter /usr anzulegen. Die udev-Regel ist nicht in jedem Fall notwendig (wenn der User nämlich schon in einer Gruppe ist, die Zugriff auf die betreffenden Devices hat), und den Desktop-Tand braucht man auch nicht unbedingt.

Natürlich kann man mit etwa fakeroot arbeiten, und das wäre vermutlich auch sauberer – aber auch das dauert länger, als ein einfacher unshare-Aufruf.