sudo su verbieten

atec

auf der Suche
Hallo @ all.
Ich möchte auf meiner FBSD-Kiste der Gruppe wheel sudo für alles, bis auf eben su erlauben. Gedacht ist, auch Lokal keine möglichkeit zu haben, eine Root-Shell zu starten.
bisher habe ich dafür schon folgende dinge getan:
1. root-passwort per * ungültig markiert
2. sämtliche 'secure' markierungen aus /etc/ttys entfernt (insecure bringt nur für single-user was)
leider bringt 2. nichts für sudo su (warum weiss ich auch nicht)

Theoretisch könnte ich ja in /usr/local/etc/sudoers der Gruppe wheel einfach /usr/bin/su verbieten, allerdings könnte jeder aus wheel ja z.B. eingeben:
cp /usr/bin/su /usr/bin/rootme
rootme

und hätte damit die sperre für su ausgehebelt.
Hat das jemand schon mal hingekriegt?
Danke im Voraus,
atec
 
Root wird man einen rootlogin nicht untersagen können.
sudo visudo
sudo chpass
sudo sh
sudo csh
usw....
 
natürlich hast du recht. wenn das gehen würde, würde ich mich ja fast komplett aus dem System aussperren. Es war eigentlich ehr so gedacht, dass, falls jemand einen Exploit schreibt, weil ich zu doof war, meine kiste anständig zu administieren, es möglichst schwierig hat, eine (unter script-kiddies angeblich heiss begehrte) root-shell zu starten.
Da ich selbst in diesem Alter (15) bin, bekomme ich mit, wie dilettantisch und doch erfolgreich diese Wesen vorgehen. Das kann einem echt Angst machen.
Mir ist zwischenzeitlich eine weitere idee gekommen:

sudo su *grins*
mkdir /root/.unwichtigesachen
mv /usr/bin/su /root/.unwichtigesachen/hello_world1

oder sonstwie. also einfach die executable su verstecken (oder ganz hardcore: rm /usr/bin/su).
atec
 
Oh, oh, das mach besser nicht. Es gibt ne Menge Scripte und Programme, die dann nicht mehr laufen. grep mal z.B. in /usr/local/etc/rc.d nach su...

Wer einen rootexploit hat, ist im System.
Egal, was du da für Verrenkungen machst.
Mit deinem Vorhaben reisst du eher Löcher auf, als das du was damit absicherst.
Administration: Nur eine Person darf administrieren, alle andern haben die Finger da weg zu halten.
 
du solltest generell nur user in wheel packen, denen du vertrauen kannst und dich selbst. der rest kommt in eine andere gruppe, weil die sollen ja net root werden. dann noch die befehle, die sie ausführen dürfen per gruppe oder user ins sudoers file und gut ist.
 
natürlich hast du recht. wenn das gehen würde, würde ich mich ja fast komplett aus dem System aussperren. Es war eigentlich ehr so gedacht, dass, falls jemand einen Exploit schreibt, weil ich zu doof war, meine kiste anständig zu administieren, es möglichst schwierig hat, eine (unter script-kiddies angeblich heiss begehrte) root-shell zu starten.
Da ich selbst in diesem Alter (15) bin, bekomme ich mit, wie dilettantisch und doch erfolgreich diese Wesen vorgehen. Das kann einem echt Angst machen.
Mir ist zwischenzeitlich eine weitere idee gekommen:

sudo su *grins*
mkdir /root/.unwichtigesachen
mv /usr/bin/su /root/.unwichtigesachen/hello_world1

oder sonstwie. also einfach die executable su verstecken (oder ganz hardcore: rm /usr/bin/su).
atec

Hallo mein junger Freund :)

also ich rate Dir zu etwas ganz anderen nähnlich zu einem sehr guten Buch,
Forbidden Code

Deutsche Ausgabe des Buches "Hacking - The Art Of Exploitation".

http://www.mitp.de/vmi/mitp/detail/pWert/1667/titel/Forbidden Code

Dann um mal sein eigenes Verhalten und seiner Mitmenschen zu hinterfragen,

Die Kunst der Täuschung. Risikofaktor Mensch

http://www.amazon.de/Die-Kunst-Täus.../ref=pd_sim_b_njs_title_4/028-1940375-9450943

Hoffe Du liest gerne :)

gruss rudy
 
Man könnte wenn man cool ist / als read only mounten, und die nötigsten sachen rw mounten (/var, /tmp, /home) aber die dann mit -o noexec.
 
Man könnte wenn man cool ist / als read only mounten, und die nötigsten sachen rw mounten (/var, /tmp, /home) aber die dann mit -o noexec.
Das ist mit FBSD ports ziemlich nervig, da AFAIK die ports in /tmp zum Basteln ab und zu exec Rechte brauchen, sowie in /var/db/pkg die Skelete für die entsprechenden install/deinstall scripte. Wer die zusätzliche Arbeit nicht scheut, kann dann aber auch gleich alles gut verlinken, /usr auch noch ro nehmen, /var und /usr auf nodev und paranoiderweise alles bis auf / und die jails platte auf nosuid ;) Dann gibts da noch chflags, aber im Notfall häufen sich dann nur noch die Beinschüsse :p
 
hallo nochmal
@ rudy: "...Ganz abgesehen davon, dass niemand in einer Organisation arbeiten will, in der das oberste Gesetz "Traue niemandem" heißt. ..." genau das ist das Problem. Aber das erste buch klingt sehr interessant. Für social engineering bin ich nicht der Typ.

Stellt euch das ganze so vor: eine kleine Gruppe (5 Personen) hat einen ebenso kleinen PC mit FreeBSD bestückt und per DynDNS mit dem Internet verbunden, um darauf für den Privaten gebrauch diverse Server laufen zu lassen. Nun weiss ich aber, dass meine Mitmenschen als Passwort z.B. ihr Geburtsdatum missbrauchen, was ich ja schwerlich unterbinden kann (oder doch?).
Der einfachen Benutzbarkeit wegen sollte jeder dieser 5 Menschen die möglichkeit haben, diverse Administrationsaufgaben zu erledigen, um den aufwand für den einzelnen klein zu halten. Deshalb sind alle 5 "wheel"-Mitglieder.
Da der Computer nun ja jedem über das Internet zugänglich ist, sehe ich die gefahr, das ein Account kompromittiert werden könnte.
Ursprünglich hatte ich gedacht, das die /etc/ttys nicht nur root-login sondern auch eine root-shell (egal auf welchem wege) verbieten kann.
Da das nicht ging, überlegte ich mir, was der am häufigsten verwendete "Trick" unter den meisten pubertierenden Jugendlichen ist, eine root-shell zu bekommen. Man glaubt es kaum, aber eben einfach nur "sudo su", egal das man mit sudo schon die volle Macht hat, egal das man es auch ein bisschen Variieren könnte (wie FreeBSDuser und troll richtig meinte).
 
wie stellen die leute denn dann die verbindung zum pc her? ssh? das ist leicht vor unbrauchbaren passwörtern zu schützen
 
vielleicht solltet ihr, wenn es eh nur wenige sind, überlegen, ob nicht sftp/scp angebrachter ist. clients gibts ja auch für alle betriebssystem und es braucht nur ein port geöffnet zu werden. mit pf können die scriptkiddies direkt in einen blocking table geschoben werden.
 
hallo nochmal
@ rudy: "...Ganz abgesehen davon, dass niemand in einer Organisation arbeiten will, in der das oberste Gesetz "Traue niemandem" heißt. ..." genau das ist das Problem. Aber das erste buch klingt sehr interessant. Für social engineering bin ich nicht der Typ.

Stellt euch das ganze so vor: eine kleine Gruppe (5 Personen) hat einen ebenso kleinen PC mit FreeBSD bestückt und per DynDNS mit dem Internet verbunden, um darauf für den Privaten gebrauch diverse Server laufen zu lassen. Nun weiss ich aber, dass meine Mitmenschen als Passwort z.B. ihr Geburtsdatum missbrauchen, was ich ja schwerlich unterbinden kann (oder doch?).
Der einfachen Benutzbarkeit wegen sollte jeder dieser 5 Menschen die möglichkeit haben, diverse Administrationsaufgaben zu erledigen, um den aufwand für den einzelnen klein zu halten. Deshalb sind alle 5 "wheel"-Mitglieder.
Da der Computer nun ja jedem über das Internet zugänglich ist, sehe ich die gefahr, das ein Account kompromittiert werden könnte.
Ursprünglich hatte ich gedacht, das die /etc/ttys nicht nur root-login sondern auch eine root-shell (egal auf welchem wege) verbieten kann.
Da das nicht ging, überlegte ich mir, was der am häufigsten verwendete "Trick" unter den meisten pubertierenden Jugendlichen ist, eine root-shell zu bekommen. Man glaubt es kaum, aber eben einfach nur "sudo su", egal das man mit sudo schon die volle Macht hat, egal das man es auch ein bisschen Variieren könnte (wie FreeBSDuser und troll richtig meinte).

Moin mein junger Freund :)

also habe ich auch garnicht so gemeint, sry wenn das vielleicht so rüberkam :( wollte eigentlich nur darauf hinweisen das es immer gut seinen Horizont zu erweitern und nicht betriebssystemblind zu werden.

Am Sonntag lief ein guter Film um 20:15 auf Pro7, da zeigt Gene Hackmann per par exellence wie social engineering funktioniert.
Szene:
Taxi er steigt ein schaut sich um, was sieht er ein Kreuz und Bilder von der Mutter des Taxifahrers und dessem Frau, ein Blick in den Rückspiegel des Taxis genügt Gene Hackmann um zu sehen das der Fahrer einen betrübten Eindruck macht.
Er fängt nun ein Gespräch mit dem Taxifahrer an und stellt diesem nur ein zwei Fragen was er daraus analysiert ist schlicht genial.

Kranke Mutter und mehr als schlecht gelaunte Ehefrau die dem armen Taxifahrer sehr belasten.

Ja und soetwas funktioniert sehr gut, bei uns in der Firma werden unsere Sicherheitsbereiche und das Personal ähnlichen Tests unterzogen.

Gruss rudy
 
@ rudy: keine angst, ich hab das nicht in den falschen Hals gekriegt.
Ich bewundere ebenfalls solche Menschen, die über so eine phänomenale Menschenkenntnis verfügen und diese so gezielt einsetzen können.
Auf was ich dich hinweisen wollte war (dieses Problem begegnet mir bei uns in der DLRG immer wieder), was ja auch in der Buchbeschreibung stand, du kannst entweder alles alleine machen, dann hast du eben die ganze Arbeit am Hals und keiner mag dich, oder du verteilst die Aufgaben (egal ob du es jetzt als Autorität tust oder es durch gleichberechtigung quasi Automatisch geht), Dadurch kommen wir automatisch bei Usability!=sicherheit raus. Du machst alles alleine -> keiner braucht deinen Computer.
Du lässt die Leute machen was sie wollen -> du verbringst die nächsten 5 Jahre im Knast, weil dein Computer als illegale Tauschbörse missbraucht wurde.
Aber backt to topic:
Ich versuche, einen "gesunden" Mittelweg zu finden. Genannte 5 Leute sind langzeitige, sehr gute Freunde und vertrauen einander. Deshalb dürfen alle 5 alles. Doch da kam eben das nächste Problem mit der Sicherheit der Passwörter von einigen der 5.

alles klar? ;-))

EDIT: bald hab ich mal wieder Geburtstag, mal gucken, ob ich das "Forbidden Code" kriegen kann. Im moment leide ich unter notorischer Geldnot.
EDIT2: hast du die Bücher eigentlich mal gelesen?
 
je nachdem was jeder der fünf machen soll würde ich das explizit erlauben.
also alle aus der Gruppe whell rausnehmen und
makenoob schrieb:
dann noch die befehle, die sie ausführen dürfen per gruppe oder user ins sudoers file und gut ist.
 
ja das wird's wohl sein
frage: braucht man eigentlich die wildcards für argumente von befehlen?
 
Zurück
Oben