Security fail pt2: Userauthentifizierung in BASH

Um die Security awareness etwas zu erhöhen, habe ich überlegt, noch ein paar witzige Schnippsel zu posten! Vielleicht entdeckt ja jemand auch etwas, das er selbst mal gemacht hat!
Hier folgt nun ein sinngemäßer Auszug aus einem Script, das bei einem ISP sehr kritische Aktionen für Domains ausführt:
#!/bin/bash
if [ "$USER" != "franz" ] && [ "$USER" != "karl" ]
then
echo "Zugriff verweigert."
else
[...]
echo "$(date) Domain $1 gelöscht durch $USER" >> /var/log/domainlog
fi
Wichtig ist hier vor allem das Audit Log. Umgehen kann man es jedoch trivial:
USER=franz ./domain-delete.sh [domain]
Leider bedachte der Programmierer nicht, dass $USER natürlich trivial von jedem Shelluser geändert werden kann. Das Audit-Log würde ggfs. sehr unerfreuliche Folgen haben.
Bessere Lösung: sudo benutzen und nur den zwei Usern, die es wirklich benötigen, Rechte auf das Script gewähren.
Related posts:
- Security fail pt3: Userauthentifizierung über externe Kommandos Tim schlug hier vor, im Vorpost etwas anderes zur Authentifizierung als $USER zu nutzen:...
- Security fail pt1: sudo chmod/chown Auf einem Webserver fand ich kürzlich eine sudoers-Zeile, die einem User erlaubte, chmod und...
- Security fail pt4: Backups Auch immer wieder gesehen: falsche Berechtigungen von Backups. [user@srv2342 ~]$ ls -l /opt/backup -rw-r--r-- 1...
- Bash Completion unter Debian Etch Die Autovervollständigung ist schon eine sehr hilfreiche Funktion der Bourne Again Shell. Um diese unter...
- Squid url_rewrite Performance Hier ein Tipp für Sysadmins, die url_rewrite in Squid nutzen: schaut euch genau an,...



Andreas
oder sich mal op anschauen. Auch sehr nett und es hat mittlerweile den Vorzug vor sudo bei mir bekommen.
Christian
Ähm, mal ganz doof, reichts nicht eine Gruppe für die beiden anzulegen (Beispiel suser), dann
chown root:suser domain-delete.shgefolgt vonchmod 750 domain-delete.shNur mal so ne Überlegung…
Frank
Gruppen haben das Problem, dass sie z.B. über NFS zahlenmäßig limitiert sind. Außerdem verliert man schnell den Überblick für was die Gruppe gut war, gerade wenn man für jeden Kleinsch… eine Neue anlegt.
stefan
@Christian: ja, aber man möchte ein Audit-Log schreiben, daher der Vorschlag, sudo zu benutzen. Außerdem soll ja der User vielleicht garnicht sehen können, was in der Datei steht, daher wäre 750 vielleicht eher ungünstig.
Prinzipiell hast du natürlich recht, es geht auch anders, je nach Use-Case usw.
@Frank: naja, so schnell wird man hier wohl nicht an das Gruppenlimit kommen!
Außerdem: Doku schreiben, in der steht, was warum eingerichtet wurde, sollte man schon, alles andere gehört sich nicht, sofern man den Anspruch hat, professionell zu sein…
Frank
@Stefan: da kommt man extrem schnell hin. Standard sind nämlich nur 16 Gruppen, IIRC.
Ich hatte über NFS mal eine kleine Nutzerstruktur aufgebaut, wo es so ca. 8-10 Gruppen gab und die Nutzer in verschiedener Kombination etwas auf dem NFS Server zugreifen sollten. Da musste dann ein Patch ran, ansonsten fehlten den einzelnen Nutzern ein oder zwei Gruppen, sprich das meiste ging, aber ein paar Verzeichnisse waren nicht zugreifbar…
Mit der Doku geb ich dir prinzipiell Recht, aber /etc/sudoers zählt doch eigentlich als Doku
Claus
Nicht dass es eine große Rolle spielt, aber in der if-Bedingung müßte es AFAIK “&&” heißen, denn eine der beiden Bedingungen wird immer TRUE ergeben…
Tim
Oder statt mit $USER einfach mit dem netten Befehl id -n arbeiten, der lässt sich imho nicht so leicht fälschen…
stefan
@Claus: klar! Danke.
@Frank: http://nfsworld.blogspot.com/2005/03/whats-deal-on-16-group-id-limitation.html
Wow, so eine Altlast – gut, dass ich kein NFS nutzen muss.
@Tim: Je nach Benutzung schon – siehe nächster Post.