fablab schriebGerBra schrieb
Ha! Niemals nicht su ohne -, -l, oder --login verwenden ;-) Fallstricke vorprogrammiert.
Tip: schau dir mal env mit und ohne explizites Login an (bei früheren Versionen war nicht mal $HOME geändert, richtig böser Fallstrick, ich sage nur .Xauthority... //Edit: und $PATH kann für den unachtsamen root-Admin richtig böse werden...)
Hallo GerBra, kannst Du das genauer erläutern?
Ja, kann ich, anhand eines Beispiels.
su ohne expliziten Loginvorgang übernimmt vom aufrufenden User(bzw. dessen Sitzung) das sog. "Environment", also Parameter/Einstellungen der User-Sitzung. Das kann man sich recht einfach verdeutlichen wenn man mal su ohne und su mit Login aufruft und dort jeweils mit dem Befehl env sich die jeweilige Umgebung anschaut. Beim su ohne Login sind noch etliche Umgebungsvariablen/Verweise auf die "aufrufende" Usersitzung zu finden.
Bei mir sind das z.B. USER, PWD, MAIL, DBUS_SESSION_BUS_ADDRESS, XDG_RUNTIME_DIR und PATH.
Wenn ich also um eine root-Shell zu kriegen einfach nur su eingebe, würde ich - wenn ich mir dessen nicht bewußt wäre - in weiteren Vorgängen nicht zum root-Account passende Umgebungsvariablen verwenden, eben halt z.B. $USER, $MAIL, usw. Ich erwarte eigentlich daß $USER z.B. root wäre, ist es aber nicht. Mit su --login werden diese Variablen bzw. die ganze Umgebung hingegen "richtig" initialisiert/besetzt.
Wie gefährlich so ein "gedankenloses" su sein kann ist recht anschaulich anhand des angesprochenden PATH-Problems zu sehen. Unter eigentlich recht normalen Umständen kann sich ein User root-Rechte verschaffen.
Vorgedanke (und des Pudels Kern): Wenn mehrere gleichlautende Befehle/Programme existieren wird dass verwendet, welches im $PATH (den Suchpfaden) als erstes gefunden wird. Darüber einfach mal nachdenken bevor man/du evtl. weiterliest.
-----------------------
So: mein böser User heißt evilnerd und er möchte seinen Admin mal testen und hätte gerne Root-Rechte auf seinem Rechner, damit neben den laaaangweiligen Büroprogrammen endlich mal supertuxkart installiert werden kann.
Die $PATH-Variable unseres evilnerd lautet nun:
PATH=/home/evilnerd/bin:/usr/local/sbin:/usr/local/bin:/usr/bin:/usr/bin/site_perl:/usr/bin/vendor_perl:/usr/bin/core_perl
evilnerd plaziert nun z.B. eigenen Code in /home/evilnerd/bin (erstes Verzeichniss in der Suchliste), z.B. ein Shellskript (darf er ja, da er ja berechtigt ist zum schreiben).
#!/bin/sh
#
echo "I could do everything as root... nanananana na!" > /root/i_was_here
/usr/bin/ls $@
echo "HaHa. ich bin: $(id)"
und nennt dieses Skript ls und macht es ausführbar. Auch andere Befehle sind denkbar, einfach alles was root wohl verwenden würde/könnte.
Nun bringt evilnerd unseren gedankenlosen Admin dazu, mittels su eine Root-Shell zu öffnen:
"Hey Admin, ein ls auf mein /mnt/officedata/ funktioniert nicht oder bringt nur Fragezeichen... Hilfe!!!"
(evilnerd könnte ja wirklich ein "stimmiges" Fehlerbild produzieren, das ist dann schon anspruchsvoll...)
Der ahnungslose Admin (leidenschaftlicher su Nutzer) hämmert nun in das (passenderweise) offene Terminalfenster von evilnerd ein beherztes:
su
ein, bittet evilnerd sich doch bei der Paßworteingabe kurz wegzudrehen (schließlich soll ja nicht jeder das Root-PW kennen!) und verdeckt die PW-Eingabe sicherheitshalber noch mit dem breiten, muckibudengestählen Oberkörper. Dann schaut sich unser Admin das ganze Problem jetzt in seiner Rootshell an:
ls -lh /mnt/officedata
und bekommt folgendes zu sehen:
insgesamt 96K
drwxr-xr-x 2 petersen office 4,0K 14. Aug 2017 Workshops
drwxr-xr-x 2 petersen office 4,0K 3. Jun 17:39 Wichtig
-rw-r--r-- 1 evilnerd office 0 20. Apr 2017 blumen_gießen_im_buero.doc
HaHa. ich bin: uid=0(root) gid=0(root) Gruppen=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),19(log)
Statt /usr/bin/ls ist nun das von evilnerd plazierte Skript ausgeführt worden. Evilnerd konnte so z.B. ins eigentlich gesperrte /root/-Verzeichnis reinschreiben, bei wirklich böartigen Dingen kann man so auch leicht sich einen neuen Root(UID 0)-Account anlegen lassen, Daten löschen/manipulieren, einen Atomkrieg auslösen...
Wenn es geschickt gemacht ist, sogar unmerklich und schwer nachweisbar.
Ein: which ls zeigt das auch genau.
Und alles, weil unser gedankenloser Admin ein paar Fehler machte:
a) su eben ohne -, -l oder --login zu starten (dadurch wurde die alte PATH-Einstellung vom evilnerd-Environment übernommen)
b) ls (oder welchen Befehl auch immer) ohne explizite Pfadangabe aufzurufen (/usr/bin/ls hätte diese "Manipulation" garnicht greifen lassen)
c) Einfach su statt schon von Beginn /usr/bin/su (egal ob nun mit oder ohne Login) verwendet, für su könnte evilnerd ja auch schon ein manipuliertes su hinterlegt haben.
d) Generell sollte ein Admin nie irgendetwas aus dem Desktop/Umgebung eines Users "benutzen", z.B. das gerade offene Terminalfenster. Sondern sich (besser) wenigstens über die TTY-Textkonsolen anmelden (daß wäre dann ein vollwertiges Login).
Und ja, am besten hätte man in so einer Umgebung ein noxec für die HOME-Mounts oder Daten-Mounts, aber oftmals sind es ja auch "Normal- oder Defaultumgebungen" ohne weitere Sicherheitsaspekte.
Auf obiges Szenario (speziell eben die "$PATH-Manipulation") sind schon viele "reingefallen" bei kurzen "Testen-wir-den-Admin" Spielen.
Durch einen simplen Zusatz bei su kann dieses Beispiel schon abgewendet werden, deshalb predige ich immer für "su -" statt "su". Kostet nichts, hilft viel...
NB: einen Alias zu setzen für su (der eben su --login aufruft) ist ggf. keine gute Lösung gegen diese "Gedankenlosigkeit", da der definierte Alias ja nicht überall vorhanden sein muß.