PDA

Archiv verlassen und diese Seite im Standarddesign anzeigen : /usr/bin/sudo nicht lesbar



medhefgo
01.12.11, 23:58
Hallo,

ich habe heute etwas kurioses gefunden: /usr/bin/sudo ist nicht lesbar!


---s--x--x 2 root root 76331 Oct 28 03:34 /usr/bin/sudo

Ein kurzer Test hat mir bestätigt, dass root alle Dateien lesen kann, selbst wenn root keine Leserechte hat. Deswegen Frage ich mich: Ist das ein security by obscurity Versuch??

Und wenn ja: Wieso? Es ist ein quelloffenes Programm und man kann jedes sudo mit einem bequemen "sudo --version" identifizieren.

kreol
02.12.11, 00:44
Distri?

Hier (Deb Squeeze):
kreol@P4300:~$ ls -la /usr/bin/sudo
-rwsr-xr-x 2 root root 144740 13. Mär 2011 /usr/bin/sudoUnd wenn es so "bequem" ist, ein sudo zu "identifizieren": Warum lieferst Du diese Info für Deins nicht mit?

Kreol

derRichard
02.12.11, 01:27
Hallo,

ich habe heute etwas kurioses gefunden: /usr/bin/sudo ist nicht lesbar!


---s--x--x 2 root root 76331 Oct 28 03:34 /usr/bin/sudo

Ein kurzer Test hat mir bestätigt, dass root alle Dateien lesen kann, selbst wenn root keine Leserechte hat. Deswegen Frage ich mich: Ist das ein security by obscurity Versuch??

Und wenn ja: Wieso? Es ist ein quelloffenes Programm und man kann jedes sudo mit einem bequemen "sudo --version" identifizieren.

root hat per default alle sicherheits capabilities.
eine davon ist CAP_DAC_OVERRIDE. d.h. root darf das unix-zugriffsmodel (dac) umgehen.

da das program setuid ist, wird es immer als root ausgeführt -> root darf das binary lesen und ausführen.
der user es aber nicht lesen/schreiben.

je nach policy der distribution ist die einstellung, dass ein user das setuid-programm nicht lesen kann oft anzutreffen.
vor allem wenn es sich um ein selbst gebasteltes programm vom admin ist. ;)

hth,
//richard

marce
02.12.11, 06:51
hier auf einem CentOS sieht's genau so aus:

ls -la /usr/bin/sudo
---s--x--x 2 root root 174436 6. Mär 2011 /usr/bin/sudo

medhefgo
02.12.11, 23:12
Das root das Programm lesen kann habe ich mir schon gedacht. Ich frage mich vor allem warum unter Linux (in meinem Fall Arch) solch eine - in meinen Augen unsinnige - Lesebeschränkung nötig ist.

derRichard
02.12.11, 23:20
Das root das Programm lesen kann habe ich mir schon gedacht. Ich frage mich vor allem warum unter Linux (in meinem Fall Arch) solch eine - in meinen Augen unsinnige - Lesebeschränkung nötig ist.

wie bereits gesagt.
das wird eine default-policy für alle suid-root-programme sein...

//richard

undefined
03.12.11, 15:08
Das root das Programm lesen kann habe ich mir schon gedacht. Ich frage mich vor allem warum unter Linux (in meinem Fall Arch) solch eine - in meinen Augen unsinnige - Lesebeschränkung nötig ist.
Und wieder einer der UMASK und SUID nicht verstanden hat ;)

Der Grund warum die Jungs das setzen hat mit etwaigen Programmfehlern zu tun.

Einer der großen nachteile von SUID-Programmen ist, das sie ein erhebliches Sicherheitsrisiko darstellen, falls diese Programme fehlerhaft sind. Lokale Angreifer könnten sie dazu benutzen, um das ganze System zu kompromittieren.

Geht man aber hin und verhindert das ausführen des Programmes +(seiner Unter Prozesse) auf sich selbst (z.b. durch Puffer überläufe) kann man dies hiermit etwas minimieren.

Prozess Eigenschaften:
Zur laufzeit wird das angestossene Programm von einem Standard Benutzer als Benutzer root ausgeführt aber nicht als Gruppe root!

Wenn du aber das Programm als root ausführst wird automatisch auf die Gruppe zurück gegriffen wenn owner nicht lesbar ist.

roadracer
03.12.11, 16:47
Bei mir unter OpenSUSE 11.4 sieht das ganze so aus:
ls -la /usr/bin/sudo
-rwsr-xr-x 1 root root 181796 18. Feb 2011 /usr/bin/sudo
Scheint also ein sehr uneinheitliches Vorgehen der Distributoren...

medhefgo
03.12.11, 20:33
wie bereits gesagt.
das wird eine default-policy für alle suid-root-programme sein...

//richard

Dann wird die Policy aber nicht konsequent erzwungen...


-r-sr-xr-x 1 root root 38190 Oct 12 14:42 /bin/su

derRichard
03.12.11, 21:23
Dann wird die Policy aber nicht konsequent erzwungen...


-r-sr-xr-x 1 root root 38190 Oct 12 14:42 /bin/su

dann solltest das deiner distri melden :P

//richard