• Willkommen im Linux Club - dem deutschsprachigen Supportforum für GNU/Linux. Registriere dich kostenlos, um alle Inhalte zu sehen und Fragen zu stellen.

Probleme mit dem s-Bit unter Suse 11.3

P6CNAT

P6CNAT

Advanced Hacker
Hallo,

ich pflege meinen Rechner immer auszuschalten, wenn ich ihn nicht brauche. Dann bringt es auch nichts den sntp-Daemon die ganze Zeit laufen zu lassen. Deshalb habe ich ein kleines Script geschrieben, mit dem ich von Zeit zu Zeit (Wochen) die Uhr korrigiere.

Das Script liegt in meinem ./bin Verzeichnis, gehört root und hat das s-Bit gesetzt.

Code: 
$ ls -l Uhr_stellen.sh 
-rwsr-sr-x 1 root users 2131  4. Dez 2009  Uhr_stellen.sh
Der Kern des Scripts ist folgende Zeile

Code: 
/usr/sbin/sntp -v -P no -r pool.ntp.org
Seit der Installation von OpenSuse 11.3 kommt folgende Fehlermeldung.

Code: 
sntp options: a=2 v=1 e=0.100 E=5.000 P=2147483647.000
    d=15 c=5 x=0 op=1 l=/etc/sntp.pid f= pool.ntp.org
sntp: unable to write PID to /etc/sntp.pid
sntp: Permission denied
Das Script wird also unter root ausgeführt und hat kein Schreibrecht auf /etc ????
Wenn ich mich mit su auf root setze funktioniert das Script.

Also scheint mit dem s-bit irgendwas nicht zu stimmen.

Hat dazu jemand eine Idee?

Gruß
Georg
 
D

drcux

Hacker
http://de.linwiki.org/wiki/Linuxfibel_-_System-Administration_-_Zugriffsrechte

"Mit Hilfe des s-Flags kann die Benutzerkennung des Prozesses vom rufenden Benutzer/Gruppe in die des Besitzers / der besitzenden Gruppe umgewandelt werden, so dass passwd nun "im Auftrag" von Root die Datei /etc/passwd öffnet. Ein s-Bit darf nur bei Binärdateien gesetzt werden (keine Shellskripte)."
 
OP
P6CNAT

P6CNAT

Advanced Hacker
Oh,

ich wusste nicht, dass ich mir einen Bug zunutze gemacht hatte. Muss mir wohl was Besseres einfallen lassen.

Danke für den Hinweis und Gruß
Georg
 
J

jengelh

Guru
Jajaja die Fibel.
drcux schrieb:
Ein s-Bit darf nur bei Binärdateien gesetzt werden (keine Shellskripte)."
Zum Vergrößern anklicken....
(user-)s-Bits dürfen sehr wohl auf nicht-Binärdateien gesetzt werden. (Wenn nicht würde der Kernel das schon verhindern.) Ob es dann aber den gewünschten Effekt hat, ist eine andere Sache. Im Falle von Shellskripten wird ja nicht das Skript ausgeführt, sondern dessen Interpreter.
 
T

Tooltime

Advanced Hacker
Ich kenne da auch den Spruch, das s-Bit wird bei Scripten aus Sicherheitsgründen ignoriert. Ist natürlich Blödsinn, das s-Bit wirkt bei jedem Objekt das eine Prozess-ID hat und wie der Kollege schon richtig erklärt hat, ist das hier die Shell.

Zweiter großer Irrtum ist, wenn das s-Bit (root) gesetzt wird ein Binary automatisch mit den entsprechenden Rechten läuft. Habe das zwar noch nicht unter Linux ausprobiert, kenne das aber so von anderen Unixen, der Prozess bekommt nur die Berechtigung seine User-ID zu wechseln und dieses muss explizit angefordert werden. Sind die erhöhten Rechte nicht mehr notwendig, so kann der Prozess diese jederzeit wieder abgeben. Das ist ein wichtiges Sicherheitsmerkmal.

Dein Problem muss irgend etwas anderes sein.
 
A

Anonymous

Gast
Tooltime schrieb:
Zweiter großer Irrtum ist, wenn das s-Bit (root) gesetzt wird ein Binary automatisch mit den entsprechenden Rechten läuft. Habe das zwar noch nicht unter Linux ausprobiert,
Zum Vergrößern anklicken....

Na dann gleich mal ausprobieren ;) nimm /usr/bin/top zum Beispiel, niemand wird behaupten wollen, dass hier intern ein Grund bestehen würde, um eine root-ID anzufordern. Wenn das suid gesetzt ist, als normaler User top starten und von einer anderen Shell mit ps -efl nachschauen, und schon wirst du feststellen das läuft jetzt mit Rootrechten. Wer's dann immer noch nicht glaubt, der probiere das ganze mit der bash.

robi
 
OP
P6CNAT

P6CNAT

Advanced Hacker
Hallo,

Tooltime schrieb:
Zweiter großer Irrtum ist, wenn das s-Bit (root) gesetzt wird ein Binary automatisch mit den entsprechenden Rechten läuft.
Zum Vergrößern anklicken....
Mmh, das wird auch so gelehrt und man kann diese Behauptung in vielen Schulungsunterlagen finden.

Tooltime schrieb:
Habe das zwar noch nicht unter Linux ausprobiert, kenne das aber so von anderen Unixen, der Prozess bekommt nur die Berechtigung seine User-ID zu wechseln und dieses muss explizit angefordert werden. Sind die erhöhten Rechte nicht mehr notwendig, so kann der Prozess diese jederzeit wieder abgeben. Das ist ein wichtiges Sicherheitsmerkmal.
Zum Vergrößern anklicken....
Wie soll das "dieses muss explizit angefordert werden" gehen?
Mein Script zur Korrektur der Uhr enthält keine explizite Änderung des users und hat bis Suse 11.2 als root funktioniert. Das würde den Irrtum eigentlich stützen.

Gruß
Georg
 
OP
P6CNAT

P6CNAT

Advanced Hacker
Ups,

da habe ich zu lange überlegt und robi war schneller.

robi schrieb:
Na dann gleich mal ausprobieren ;) nimm /usr/bin/top zum Beispiel, niemand wird behaupten wollen, dass hier intern ein Grund bestehen würde, um eine root-ID anzufordern. Wenn das suid gesetzt ist, als normaler User top starten und von einer anderen Shell mit ps -efl nachschauen, und schon wirst du feststellen das läuft jetzt mit Rootrechten. Wer's dann immer noch nicht glaubt, der probiere das ganze mit der bash.
robi
Zum Vergrößern anklicken....

Das Beispiel ist sehr gut :thumbs: und deckt sich mit meinen Erfahrungen von anderen Unix Betriebsystemen.

Gruß
Georg
 
T

Tooltime

Advanced Hacker
Die Aussage beruht auf eigene Erfahrungen. Personengebundene Ultrix-Kisten, User muss den Rechner ausschalten können, sonst hätte über jeder Workstation ein Feuerdmelder installiert werden müssen. Also was macht der Unix-Neuling mit großer Klappe(ich):

  • 1. Versuch ist natürlich Script mit s-Bit, das den Shutdown ausführt, geht natürlich nicht.
    2. Versuch, Problem erkannt ein Binary muss her --> C-Programm mit s-Bit. Hat aber nur prima funktioniert wenn root es aufruft.
    3.ter Anlauf, man trifft jemanden der mehr Ahnung hat, Problem ..., Antwort na du musst ja auch user-id wechseln, eingebaut und funktioniert.
Wenn ich mir mal die man page von setuid anschaue hat sich da wohl doch einiges geändert, obwohl mir dieses Verhalten irgendwie unsympatsich ist. Ich denke mal an die Anfangszeiten von Brennprogrammen, als noch keine Unterbrechung im Datenstrom geben durfte. Wurde da nicht mkisofs u. cdrecord mit s-Bit versehen, damit sie ihre Prio erhöhen können? Wenn man dann nicht darauf achtet hätte man leicht beliebige Daten lesen oder schreiben können. Jedenfalls stand bei mir damals in der man page das man die erhöhten Rechte so schnell wie möglich zurückgeben soll, damit das Programm nicht beliebigen Unfug anstellen kann. Die Logik dahinter leuchtet mir auch ein. Wäre doch echt merkwürdig wenn Polizei, Feuerwehr und Krankenwagen ständig mit Blaulicht durch die Gegend fahren und es nur dann ausschalten wenn sie meinen es muss jetzt nicht sein.

Viellleicht war mein System der Exokt.
 
J

jengelh

Guru
Tooltime schrieb:
Zweiter großer Irrtum ist, wenn das s-Bit (root) gesetzt wird ein Binary automatisch mit den entsprechenden Rechten läuft.
Zum Vergrößern anklicken....
Das ist kein Irrtum. Das SUID-Bit führt in der Tat dazu, dass die EUID auf root gesetzt wird, womit du praktisch Rechte erhältst alles zu tun (ich lasse mal Sachen wie SELinux aus der Betrachtung außen vor).
 
OP
P6CNAT

P6CNAT

Advanced Hacker
Hi,

Tooltime schrieb:
Die Aussage beruht auf eigene Erfahrungen. Personengebundene Ultrix-Kisten, ....
Viellleicht war mein System der Exokt.
Zum Vergrößern anklicken....

Ui, ein Veteran :). Ultrix war in der Tat um einige Eigenschaften von VMS angereichert. Und der Unterschied zu den Nachfolgern ist recht groß.

Heute habe ich ein Shell Script mit owner root unter Tru64 mit dem s-bit versehen und geguckt, was passiert.
Das Script läuft unter dem normalen user, ohne root Rechte.

Gruß
Georg
 
Du musst dich einloggen oder registrieren, um hier zu antworten.
Oben