sudo -s verbieten (Zuweisen von root shell)

[-eraz-]

Ich würde gerne das dauerhafte Zuweisen von Rootrechten für einen Benutzer per sudo -s verbieten, weiß jemand ob bzw. wie ich das machen kann?

 

[marce]

wer sudo (und was) darf konfiguriert man in der sudoers-Datei. Zu editieren mit visudo.


edit sagt, da fehlte ein o

 

[-eraz-]

wer sudo (und was) darf konfiguriert man in der suders-Datei. Zu editieren mit visudo.

was echt? sudoers file?
Nix für ungut, aber so doof bin ich nun auch wieder nicht, das war nicht die Frage.

 

[marce]

dann sehe ich Dein Problem nicht. Wer was sudoen darf, wird eben genau dort definert. Sollte bei Dir da jemand zu viele Rechte besitzen - so ist eben die Konfig nicht "richtig".

[root@web1 ~]# su - wp_mpotg
-bash-3.2$ sudo -s

We trust you have received the usual lecture from the local System
Administrator. It usually boils down to these three things:

    #1) Respect the privacy of others.
    #2) Think before you type.
    #3) With great power comes great responsibility.

Passwort:
wp_mpotg is not in the sudoers file.  This incident will be reported.
-bash-3.2$

 

[-eraz-]

Das Problem ist ja, dass ich nur den einen Befehl (sudo -s) verbieten will. Soweit ich gesehen habe, werden abgesetzte Befehle im sudo Logfile nicht mitgeschrieben, wenn man sich eine root Shell dauerhaft zuweist.
Somit suche ich nach zwei Lösungsmöglichkeiten:

1.) sudo -s verbieten
oder
2.) Das Logging auch für dauerhaft zugewiesene root Shells aktivieren (was ich ebenfalls noch nicht gefunden habe)

So schaut bei mir der Eintrag im sudoers File aus:
%Domänengruppe* ALL=(ALL) NOPASSWD: ALL

* Domänengruppe bezieht sich auf eine W2K3 Active Directory Gruppe.

Was ich auch seltsam finde:
Ich bekomme die Information garnicht die bei dir erscheint. Wenn ich als User sudo -s ausführe schaut das bei mir einfach so aus:

[user@hostname ~]$ sudo -s
[root@hostname ~]#

Und plötzlich steht 'root' da und nicht mehr der username. Ich gebe zu ich habe von sudo kaum Ahnung, aber das kommt mir schon seltsam vor.

 

[marce]

hm, also ehrlich: bei der Konfiguration ist es egal, ob der User eine Shell starten darf oder nicht - er darf ja sonst eh alles.

Aber, ich hab's nicht ausprobiert, über

        pete           HPPA = /usr/bin/passwd [A-z]*, !/usr/bin/passwd root

       The user pete is allowed to change anyone’s password except for root on the HPPA machines.  Note that
       this assumes passwd(1) does not take multiple usernames on the command line.

solltest Du so Dinge wie /bin/bash (oder was Du eben als Shell eingetragen hast) ausnehmen können.

Aber - ebenfalls in der man-Page:

SECURITY NOTES
       It is generally not effective to "subtract" commands from ALL using the ’!’ operator.  A user can triv-
       ially circumvent this by copying the desired command to a different name and then executing that.  For
       example:

           bill        ALL = ALL, !SU, !SHELLS

       Doesn’t really prevent bill from running the commands listed in SU or SHELLS since he can simply copy
       those commands to a different name, or use a shell escape from an editor or other program.  Therefore,
       these kind of restrictions should be considered advisory at best (and reinforced by policy).

Bedenke dabei bitte auch, daß z.B. Tools wie vi, more, ... die Möglichkeit bieten, eine Shell zu öffnen. Die wird dadurch nicht abgefangen - das müsstest Du also separat konfigurieren.
.
.
.
EDIT (autom. Beitragszusammenführung) :
.

Was ich auch seltsam finde:
Ich bekomme die Information garnicht die bei dir erscheint. Wenn ich als User sudo -s ausführe schaut das bei mir einfach so aus:

klar. Bei Dir darf jeder User aus der Gruppa ja alles. Und wenn Du dann eben das sudo ausführst, dann macht er es eben auch.

Und plötzlich steht 'root' da und nicht mehr der username. Ich gebe zu ich habe von sudo kaum Ahnung, aber das kommt mir schon seltsam vor.

Ernsthaft: Dein Sudo-Konzept ist keines :-) Mit Deiner jetzigen kannst Du auch einfach jedem das root-PW geben, das macht es für alle einfacher.

Sudo wird eigentlich eher dazu verwendet, einem User, der _nichts_ darf, einzelne Befehle zu erlauben - nicht alles zu erlauben, und ihm dann einzelne Befehle wieder wegzunehmen. Das bringt meistens nämlich nichts.

Ich würde erst mal anfangen, zusammenzutragen, was die einzelnen User denn können müssen - und darauf aufbauend dann die Sudo-Konfiguration zu erstellen.

 

[daboss]

Ist halt das Standard-sudo-File aus mind. Ubuntu oder Suse... (ok, wobei man zumindest bei letzterer immhin noch das root-pw wissen muss...)
Aber mit den Beispielen aus der man sollte ein entsprechendes umkonfigurieren nicht mehr so des Problem sein, eigentlich

 

[marce]

bei sudo muss man kein root-PW wissen (auch nicht bei Suse) - das ist ja eben der Gedanke hinter sudo.

 

[-eraz-]

Ernsthaft: Dein Sudo-Konzept ist keines :-)

Den Gedanken kann ich natürlich nachvollziehen Trotzdem, es macht schon Sinn warum ich das so mache.

Erklärung:
Ich und meine Kollegen in der gleichen Gruppe sind Admin's auf den Servern. Das heisst, wir müssen sowieso alles können. Der root User soll in Zukunft garnicht mehr verwendet werden. Der Grund ist einfach der, dass nachvollziehbar sein muss wer, wann, was gemacht hat und das geht eben nur mit einem personalisierten User. Geloggt wird dann sozusagen über sudo. Sudo ist für unsere Admin Gruppe also nur dafür da, um ein Logging über die durchgeführten Tätigkeiten zu haben.

Zusätzlich sind im sudoers File noch mehrere Gruppen definiert, die den Server z.b. nur neu booten können, oder Dienste neu starten dürfen.

Ich habe nun also das Problem, dass wenn sich einer aus unserer Admin Gruppe per sudo -s die root Shell dauerhaft zuweist, sehe ich im Logfile nicht mehr was er dort drin alles gemacht hat.

Deswegen entweder die Möglichkeit sudo -s zu verbieten, oder das Logging dazu zu bringen auch nach sudo -s abgesetzte Befehle mit zu loggen.

 

[marce]

ok.

ersteres solltest Du wie gesagt darüber erreichen können, indem Du die Shell ausklammerst - wobei sich das natürlich umgehen lässt, eine saubere und dichte Konfig diesbezüglich könnte komplexer werden :-)

Für ein ded. Logging jedweder Aktion würde sich auditd anbieten (LIDS und Konsorten dürfte der Aufwand zu hoch sein)

 

[daboss]

bei sudo muss man kein root-PW wissen (auch nicht bei Suse) - das ist ja eben der Gedanke hinter sudo.

Suse 11.2 Standardinstallation:

alex@linux-90nd:~> sudo cat /etc/sudoers | grep target
root's password:
Defaults targetpw # ask for the password of the target user i.e. root
ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!
alex@linux-90nd:~

 

[marce]

Ok. Kann man konfigurieren.

Macht aber nur Sinn, wenn man auch entsprechend die restliche Konfig bearbeitet hat.

 

[gropiuskalle]

Suse 11.2 Standardinstallation:
[...]

SuSE besitzt in der Standardinstallation lediglich eine default-sudoers ohne jegliche Konfiguration, d.h. niemand hat sudo-Rechte, weshalb ggf. auf root "umgebogen" wird. Deswegen finde ich es immer so widersinnig, wenn in Foren massenweise 'sudo'-Kommandos gepostet werden, obwohl die per default nur auf *Ubuntus sinnvoll sind.

 

[pferdefreund]

Wir reden doch von "open Source". Wer hindert dich denn daran, sudo selbst
zu compilieren und den Parameter s abzufangen ? - Richtig - niemand.

 

[Gast123]

@gropiuskalle:
Gneau.
Dafür gibts "$su - -c"!

 

[-eraz-]

Wir reden doch von "open Source". Wer hindert dich denn daran, sudo selbst
zu compilieren und den Parameter s abzufangen ? - Richtig - niemand.

Was mich daran hindert? Ganz einfach, der RedHat support. Auf produktiv Server werden keine Pakete selbst kompiliert, da ansonsten auch der Support dafür verloren geht. Ist eben hier ein bisschen was anderes als wenn man zuhause rum fummelt.