direktes 'su -' verbieten

[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

[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:

Code: Alles auswählen

chmod go-x /bin/su

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.

[MSfree]

Denn mittels sudo haben ohnehin alle die Möglichkeit Root zu werden

Das sollte das Problem lösen:

Code: Alles auswählen

chmod go-x /bin/su

Wenn jeder per sudo root-Rechte bekommen kann, dann kann auch jeder

Code: Alles auswählen

sudo chmod +x /bin/su

ausführen

Auch die Einschränkungen in /etc/sudo.conf kann jeder mittels

Code: Alles auswählen

sudo vi /etc/sudo.conf

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.

[TRex]

Sicherheitslücke heißt sudo und nicht su.

Die Konfiguration ohne Einschränkungen ist die Sicherheitslücke.

[breakthewall]

Wenn jeder per sudo root-Rechte bekommen kann, dann kann auch jeder

Code: Alles auswählen

sudo chmod +x /bin/su

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.

[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

[Radfahrer]

Wie breakthewall schon schrieb:
Vergebe ein root-Passwort, das die Nutzer nicht kennen. Dann kann auch keiner mehr als root arbeiten.

[MartinV]

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:

Code: Alles auswählen

sudo su -

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:

Code: Alles auswählen

foo ALL=/usr/bin, !/usr/bin/passwd, !/usr/bin/su

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

[TomL]

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:

Code: Alles auswählen

alias sudo="pkexec $@"

Da werden dann wahrscheinlich etliche dabei sein, die nicht mal den Unterschied bemerken... *lol*

[breakthewall]

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.

[uname]

Kann man nicht /etc/pam.d/su anpassen?

[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

[rendegast]

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.

[TomL]

....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.

[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