Seite 1 von 1
direktes 'su -' verbieten
Verfasst: 16.02.2018 13:19:50
von vicodas
Hallo,
wir möchten sicherstellen, das alle user ausschließlich mittels sudo administrative Aufgaben erledigen.
Es wird deshalb in einer sudo conf Datei ein direkter Aufruf von 'sudo su -' unterbunden.
Code: Alles auswählen
User_Alias SYSADMINS = user1, user2, user3
Cmnd_Alias SU = /bin/su,/usr/bin/nice
Cmnd_Alias SHELLS = /bin/sh, /bin/bash, /bin/ksh
SYSADMINS ALL = ALL, !SU, !SHELLS
Natürlich wird dies umgangen, indem z.B. eine Bash Datei mit dem Aufruf 'su -' oder ein Link zum su Binary angelegt wird.
Gibt es hier einen Weg dies komplett zu unterbinden und die User sudo aufzuzwingen?
vG
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 14:12:13
von breakthewall
Bestimmte Verfahrensweisen forciert man am besten, indem die Existenz von Alternativen vermeidet. Nur in diesem Fall wäre ein Löschen von /bin/su, wieder unnötig und kontraproduktiv, da das bei einem Upgrade wieder neu erstellt werden kann. Also nimmst allen Nutzern einfach die Rechte bzw. Ausführrechte an /bin/su, womit kein Nutzer abgesehen von Root, länger darauf zugreifen kann. Denn mittels sudo haben ohnehin alle die Möglichkeit Root zu werden.
Das sollte das Problem lösen:
Andererseits ist es bei sudo ohnehin Standard, dass jeweilige Nutzerpasswort zu verwenden. Damit könntest auch alles so lassen wie es ist, und schlicht ein Rootpasswort setzen was nur Dir bekannt ist.
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 14:20:56
von MSfree
breakthewall hat geschrieben: 
16.02.2018 14:12:13
Denn mittels sudo haben ohnehin alle die Möglichkeit Root zu werden
Das sollte das Problem lösen:
Wenn jeder per sudo root-Rechte bekommen kann, dann kann auch jeder
ausführen
Auch die Einschränkungen in /etc/sudo.conf kann jeder mittels
auf "seine Bedürfnisse" anpassen.
Durch erzwingen von sudo und verbieten von su wird ein System jedenfalls keinesfalls sicherer, die Sicherheitslücke heißt sudo und nicht su.
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 14:35:06
von TRex
MSfree hat geschrieben: 16.02.2018 14:20:56
Sicherheitslücke heißt sudo und nicht su.
Die Konfiguration ohne Einschränkungen ist die Sicherheitslücke.
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 14:36:44
von breakthewall
MSfree hat geschrieben: 16.02.2018 14:20:56
Wenn jeder per sudo root-Rechte bekommen kann, dann kann auch jeder
ausführen
Natürlich geht das. Darum muss auch eine saubere Konfiguration in der sudoers angelegt werden, wo man prinzipiell allen Nutzern verbieten könnte, die Rechte oder die Konfiguration zu verändern. Man kann selbstredend auch direkt alles verbieten, bis auf bestimmte administrative Funktionen pro Nutzer. Behält man jedoch die Standardeinstellungen bei, dann muss man sich nicht wundern. Und letztlich will er sudo haben, unabhängig davon wie problematisch es sein kann, insbesondere wenn man nicht weiß was man da tut. Muss jeder selbst wissen.
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 15:16:23
von vicodas
Danke für das schnelle Feedback.
Uns geht es hier primär nicht um mehr Sicherheit, sondern wir möchten dokumentieren wer was auf der Maschine macht.
Wenn jeder als root arbeitet ist das schwer nachzuvollziehen.
vG
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 16:48:28
von Radfahrer
Wie breakthewall schon schrieb:
Vergebe ein root-Passwort, das die Nutzer nicht kennen. Dann kann auch keiner mehr als root arbeiten.
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 17:12:59
von MartinV
Radfahrer hat geschrieben: 16.02.2018 16:48:28
Wie breakthewall schon schrieb:
Vergebe ein root-Passwort, das die Nutzer nicht kennen. Dann kann auch keiner mehr als root arbeiten.
Das ist leider keine Lösung. Was dann immer noch geht:
Wenn ich es richtig verstehe, soll mit sudo alles erlaubt werden, außer explizit su. Man kann einzelne Befehle in der /etc/sudoers ausdrücklich verbieten, doch das läßt sich auch umgehen, eine wirklich sichere Lösung gibt es nicht.
Hilfreich finde ich diesen Beitrag:
https://askubuntu.com/a/500805
Denkbar ist dieser Eintrag für user foo in /etc/sudoers:
Das erlaubt ihm, außer su alles in /usr/bin auszuführen. Passwort ändern mit passwd kann er nur für sich selbst (ohne sudo), nicht für andere. Wichtig: foo darf nicht in Gruppe sudo sein.
Auch das ist nicht sicher, er kann z.B. /bin/su kopieren, einen anderen Namen /bin/mysu geben und das dann ausführen.
Edit: Sorry, ich hätte den Eingangspost genauer lesen sollen, Du hast das ja schon umgesetzt und zusätzlich noch die Shells verboten.
Generell ist es sinnvoller, nur ausdrücklich erlaubte Aktionen in /etc/sudoers zu definieren als nachträgich welche auszuschließen.
Uns geht es hier primär nicht um mehr Sicherheit, sondern wir möchten dokumentieren wer was auf der Maschine macht.
Wenn jeder als root arbeitet ist das schwer nachzuvollziehen.
Wenn es in erster Linie um das Logging geht, gibt es auch Möglichkeiten, "sudo su" zu loggen:
https://unix.stackexchange.com/a/109836
Re: direktes 'su -' verbieten
Verfasst: 16.02.2018 18:38:32
von TomL
vicodas hat geschrieben: 16.02.2018 13:19:50
Gibt es hier einen Weg dies komplett zu unterbinden und die User sudo aufzuzwingen?
Gibt es technische Gründe, warum ihr das nicht über das Policykit löst und ganz auf sudo und sudoers verzichtet...?... das Polkit kann das doch alles.
Beispielsweise explizit eine App für alle User oder für eine Gruppe von User sperren... ich habe das hier mal mit lxterminal getestet, um mich nicht selber beim basteln mit "/bin/su" auszusperren (...und hätte zur Not auf xterm ausweichen können). Aber prinzipiell wäre es mit "su"das gleiche.
Code: Alles auswählen
pkexec /usr/bin/lxterminal
Error executing command as another user: Not authorized
This incident has been reported.
Andersrum gehts natürlich auch, bestimmte Anwendungen einem User oder einer Gruppe erlauben.
Für alles andere, was erlaubt ist, werden Logeinträge erstellt... und man muss da noch nicht mal viel für machen, es funktioniert einfach.
Code: Alles auswählen
Feb 16 18:19:11 thomaspc pkexec[4573]: thomas: Executing command [USER=root] [TTY=unknown] [CWD=/home/thomas] [COMMAND=/usr/sbin/synaptic]
Feb 16 18:20:09 thomaspc pkexec[4593]: thomas: Executing command [USER=root] [TTY=unknown] [CWD=/home/thomas] [COMMAND=/usr/sbin/gparted]
Feb 16 18:21:55 thomaspc pkexec[4830]: thomas: Executing command [USER=root] [TTY=/dev/pts/0] [CWD=/home/thomas] [COMMAND=/bin/nano /etc/ssh/sshd_config]
Feb 16 18:23:56 thomaspc pkexec[5065]: thomas: Executing command [USER=root] [TTY=/dev/pts/0] [CWD=/home/thomas] [COMMAND=/bin/cp /etc/ssh/sshd_config /home/thomas]
Feb 16 18:27:06 thomaspc pkexec[5133]: thomas: Executing command [USER=root] [TTY=/dev/pts/3] [CWD=/home/thomas] [COMMAND=/usr/local/bin/mc-wrapper]
Und wenn man die sudo-Anwender nicht "umgewöhnen" kann, erstellt man einfach einen Alias:
Da werden dann wahrscheinlich etliche dabei sein, die nicht mal den Unterschied bemerken... *lol*
Re: direktes 'su -' verbieten
Verfasst: 17.02.2018 04:34:40
von breakthewall
TomL hat geschrieben: 16.02.2018 18:38:32
Gibt es technische Gründe, warum ihr das nicht über das Policykit löst und ganz auf sudo und sudoers verzichtet...?... das Polkit kann das doch alles.
Zu meiner Schande muss ich sagen, dass ich mich bislang noch nie wirklich mit Polkit beschäftigt habe. Dabei ist das eine unheimlich praktische Sache, die komplexere Sicherheitslösungen mitunter überflüssig macht. Und von diesem Standpunkt aus, ist das natürlich ein wirksamer Ansatz.
Müsste mich ohnehin noch korrigieren bezüglich der Rechtevergabe. Da die regulären Dateirechte ebenfalls durch Upgrades zurückgesetzt werden können, wo ACLs die bessere Wahl wären.
Re: direktes 'su -' verbieten
Verfasst: 17.02.2018 09:41:57
von uname
Kann man nicht /etc/pam.d/su anpassen?
Re: direktes 'su -' verbieten
Verfasst: 17.02.2018 10:41:12
von habakug
Hallo,
wenn man nach dem Debian-Wiki [1]
sudo konfiguriert hat, kann man diese Zeile (wie oben schon ähnlich vorgeschlagen) anpassen:
Code: Alles auswählen
# Allow members of group sudo to execute any command
%sudo ALL=(ALL:ALL) ALL
Daraus wird:
Code: Alles auswählen
# Allow members of group sudo to execute mostly any command
%sudo ALL=(ALL:ALL) ALL !/bin/bash,!/usr/bin/su
Hinter dem Komma sollte kein Leerzeichen sein.
Gruss, habakug
[1]
https://wiki.debian.org/sudo
Re: direktes 'su -' verbieten
Verfasst: 17.02.2018 13:09:54
von rendegast
TomL hat geschrieben:
Gibt es technische Gründe, warum ihr das nicht über das Policykit löst und ganz auf sudo und sudoers verzichtet...?... das Polkit kann das doch alles.
Wenn ich in 'man pkexec' lese
... simply write an action definition file like this
..... (folgendes xml-Beispiel)
resp. die Beispieldatei org.freedesktop.policykit.policy
schreckt mich das erstmal ab.
Weiterhin die Komplexität des framework mit *authority* (Allein der Ausgangszustand von /etc/polkit-1/) und der Umfang von
policykit-1-doc.
Re: direktes 'su -' verbieten
Verfasst: 17.02.2018 20:19:26
von TomL
rendegast hat geschrieben: 17.02.2018 13:09:54
....schreckt mich das erstmal ab.
Ja, das verstehe ich...
... das ist wirklich ein abschreckendes Beispiel... aber um beim Sprachgebrauch zu bleiben, wenn man sich mal damit auseinander gesetzt hat, erkennt man, dass das erschreckend plausibel und gut gelöst ist.
Letztendlich reduziert sich eine Policy auf diese wenigen sehr eindeutigen Statements:
Code: Alles auswählen
<action id="LocalExtPerms.sudo">
<defaults>
<allow_any>auth_admin</allow_any>
<allow_inactive>auth_admin</allow_inactive>
<allow_active>auth_admin</allow_active>
</defaults>
<annotate key="org.freedesktop.policykit.exec.path">/usr/local/bin/sudo</annotate>
<annotate key="org.freedesktop.policykit.exec.allow_gui">true</annotate>
</action>
- Als erstes die ID, hier die von mir erfundene ID "LocalExtPerms.sudo", die zur Identifkation (für PKLA-Files) benötigt wird.
- Dann die drei allow-direktiven, die implizite Berechtigungen auf alle Clients, auf inaktive Sitzungen (SSH) und aktive Sitzungen (lokale Anmeldung) regeln.
- Als nächstes folgt das Programm, das geregelt werden soll, hier /usr/local/bin/sudo.
- Und zum Schluß ein zusätzliches Statement, wenn das Programm eine GUI-Anwendung ist, worauf man bei Terminal-Apps jedoch verzichten kann.
Diese Beispiel-Policy ist bei mir für ein Bash-Script, welches sudo emuliert.
Ja... und was feht noch... der Header drum rum... gut, den brauch man.... und wenn man drauf steht, auch noch Description- und Message-Statements, die ich allerdings nicht verwende. Man kann in eine Rule eine Policy eintragen oder viele. Man kann viele Rules erstellen, die jeweils eine oder mehrere thematisch zusammenhängede Policies beinhalten können..... das geht alles.
Leider hält Debian auch bei Stretch immer noch an den alten PKLA-Files fest, statt auch da den XML-Style zu verwenden... und geht damit meiner Meinung nach entgegen der eigentlichen Entwicklung des Polkits den falschen Weg.... aber so isses halt. PKLA steht für
PolicyKit local authorization. Über diese Files kann eine Policy zusätzlich auch auf User und Gruppen angewendet werden, entweder erlauben, oder verbieten, oder beides für unterschiedliche Gruppen/User.
Wenn man beispielsweise einen solchen sudo-wrapper in Verbindung mit dem Polkit verwenden würde, könnte man vorher oder nachher (pkexec) einen beliebigen Logeintrag über das eingegebene Statement schreiben... in Abhängigkeit davon, ob das sudo-statement erfolgreich war oder nicht.
Ob das hier für die Eingangsfrage praktikabel ist... *hmmm*... kann ich nicht einschätzen... aber ich halte es für empfehlenswert, mal einige Tage zur Einarbeitung zu opfern.
Re: direktes 'su -' verbieten
Verfasst: 19.02.2018 07:20:34
von vicodas
Hallo,
vielen Dank für die Anregungen.
Ich werde das die Woche mal testen und berichten ob es in unsere Umgebung passt.
Hintergrund ist, das wir zwar primär auf Debian setzen, aber auch noch einige Oracel EL haben.
Diese sollten analog konfiguriert werden und funzen.
thx