suid - Bit
Roland
Ich hab' mir ein Skript geschrieben um ein Programm etwas flüssiger zu
betreiben:
nice --10 Programm
Das Skript gehört root.
Die Rechte sind auf 755 gesetzt.
Wenn das Suid-Bit gesetzt ist, dann sollte der Prozess alle Rechte des
Besitzers (= root) bekommen, oder?
Jedenfalls kommt das folgende, wenn man das Skript als normaler Benutzer
startet:
nice: cannot set priority: Permission denied
Warum?
Danke,
Roland();
August Hörandl
das suid bit wird bei scripts (aus sicherheitsgründen) ignoriert
beispiel
in deinen script fast steht
nice --10 $*
mit suid kann jedermann mit
fast rm -r /
die harddisk löschen - sogar mit hoher priorität ;-)
tip:
man sudo
Gustl
--
August Hoerandl hoer...@elina.htlw1.ac.at
Theorie ist, wenn man alles weiß und nichts klappt. Praxis ist, wenn
alles funktioniert und keiner weiß warum. Bei Windows 9* sind Theorie
und Praxis vereint, nichts funktioniert und keiner weiß warum.
Roland
>
> Roland wrote:
> >
> > Hallo!
> >
> > Ich hab' mir ein Skript geschrieben um ein Programm etwas flüssiger zu
> > betreiben:
> >
> > nice --10 Programm
> >
> > Das Skript gehört root.
> > Die Rechte sind auf 755 gesetzt.
> > Wenn das Suid-Bit gesetzt ist, dann sollte der Prozess alle Rechte des
> > Besitzers (= root) bekommen, oder?
> > Jedenfalls kommt das folgende, wenn man das Skript als normaler Benutzer
> > startet:
> >
> > nice: cannot set priority: Permission denied
> >
> > Warum?
> >
>
> das suid bit wird bei scripts (aus sicherheitsgründen) ignoriert
>
> beispiel
> in deinen script fast steht
> nice --10 $*
>
Aber root wird wohl kaum so ein Skript schreiben!
Ich meine ein bißchen Verstand muß man dem root auch zutrauen können!
Der root der SO ein Skript schreibt, der hat sowieso eine Datei
"Passwort" mit dem root-Passwort als Inhalt im /home stehen. (Und
wahrscheinlich mit einer Anleitung wie man sich einloggt...)
Kann man das nicht irgendwie abschalten?
> mit suid kann jedermann mit
> fast rm -r /
> die harddisk löschen - sogar mit hoher priorität ;-)
>
> tip:
> man sudo
>
Damit Benutzer einen mp3-Spieler starten können?
Meinst nicht das ist ein bißchen übertrieben?
Roland(der findet daß Linux langsam zu sicher wird ;-);
Wolfgang Dautermann
> August Hörandl wrote:
>>
>> das suid bit wird bei scripts (aus sicherheitsgründen) ignoriert
>>
> Aber root wird wohl kaum so ein Skript schreiben!
> Ich meine ein bißchen Verstand muß man dem root auch zutrauen können!
http://www.koehntopp.de/kris/inkomploehntopp/00385.html
http://www.koehntopp.de/kris/inkomploehntopp/00034.html
Ciao, Wolfgang
August Hörandl
>
> August Hörandl wrote:
> ...
> > das suid bit wird bei scripts (aus sicherheitsgründen) ignoriert
> >
> > in deinen script fast steht
> > nice --10 $*
> >
> Aber root wird wohl kaum so ein Skript schreiben!
> Ich meine ein bißchen Verstand muß man dem root auch zutrauen können!
sollte ja ien einfaches beispiel sein ;-)
> Der root der SO ein Skript schreibt, der hat sowieso eine Datei
> "Passwort" mit dem root-Passwort als Inhalt im /home stehen. (Und
> wahrscheinlich mit einer Anleitung wie man sich einloggt...)
> Kann man das nicht irgendwie abschalten?
nein - ist auch gut so ;-)
wenn es ein sicherheitsloch gibt - keines ist so klein das es niemand findet
wenn dein mp3 player zb das speichern eines bildes erlaubt:
user gibt als dateiname /dev/hda1 ein - naja vielleicht hast du
ja auf der ersten partition windows installiert, diesen verlust kann
man dann verkraften ...
> Roland(der findet daß Linux langsam zu sicher wird ;-);
das ist ein unix feature - und damit viel älter als linux
auf http://www.leo.org/~loescher/tips.html
gibt es beispiel für einen c-wrapper
ich würde dort nice() einfügen und dann die uid wieder auf non-root
setzen (vor der ausführung des programms) - sicher ist sicher
einfacher ist vielleicht: du erlaubst die ausführung deines scripts
mit sudo
Gustl
--
August Hoerandl hoer...@elina.htlw1.ac.at
Das Merkwürdigste an der Zukunft ist wohl die Vorstellung, daß
man unsere Zeit später die gute alte Zeit nennen wird.«
- John Steinbeck
Roland Seuhs
>
> Roland wrote:
> >
> > August Hörandl wrote:
> > ...
> > > das suid bit wird bei scripts (aus sicherheitsgründen) ignoriert
> > >
> > > beispiel
> > > in deinen script fast steht
> > > nice --10 $*
> > >
> > [Grrrrrrr]
> > Aber root wird wohl kaum so ein Skript schreiben!
> > Ich meine ein bißchen Verstand muß man dem root auch zutrauen können!
>
> sollte ja ien einfaches beispiel sein ;-)
>
> > Der root der SO ein Skript schreibt, der hat sowieso eine Datei
> > "Passwort" mit dem root-Passwort als Inhalt im /home stehen. (Und
> > wahrscheinlich mit einer Anleitung wie man sich einloggt...)
> > Kann man das nicht irgendwie abschalten?
>
> nein - ist auch gut so ;-)
>
> wenn es ein sicherheitsloch gibt - keines ist so klein das es niemand findet
>
Parameter als Kommandos ausführt, dann ist das kein Sicherheitsloch.
Wenn sich der Root nicht auskennt und nicht weiß was er tut, dann ist
sowieso alles hoffnungslos verloren.
> wenn dein mp3 player zb das speichern eines bildes erlaubt:
> user gibt als dateiname /dev/hda1 ein - naja vielleicht hast du
> ja auf der ersten partition windows installiert, diesen verlust kann
> man dann verkraften ...
>
Dann muß man halt aufpassen ;-)
> > Roland(der findet daß Linux langsam zu sicher wird ;-);
>
> das ist ein unix feature - und damit viel älter als linux
>
> auf http://www.leo.org/~loescher/tips.html
> gibt es beispiel für einen c-wrapper
> ich würde dort nice() einfügen und dann die uid wieder auf non-root
> setzen (vor der ausführung des programms) - sicher ist sicher
>
> einfacher ist vielleicht: du erlaubst die ausführung deines scripts
> mit sudo
>
OK. Ich hab mich damit abgefunden.
Roland();
Roland Seuhs
> mit sudo
Eins hab' ich noch vergessen:
sudo ist auch nicht immer das gelbe vom Ei. Z.B. wollte ich leafnode
auch als normaler Benutzer starten können. (Mit einen suid-Skript wäre
das ja kein Problem)
Mit sudo geht es aber trotzdem nicht.
Und was an einen Skript mit "fetch" als einzige Zeile als Inhalt
gefährlich sein soll, sehe ich nicht ein.
Roland();
Hubert Partl
> > > > das suid bit wird bei scripts (aus sicherheitsgründen) ignoriert
> > > Aber root wird wohl kaum so ein Skript schreiben!
> Wenn root ein Skript schreibt, daß NUR ER ändern kann und das keine
> Parameter als Kommandos ausführt, dann ist das kein Sicherheitsloch.
Es gibt - wenn ich mich richtig an die FAQ von comp.unix.questions
erinnere - noch ein anders Sicherheits-Risiko:
Wenn es sein Shell-Script gibt, das ein suid-Bit gesetzt hat,
dann kann jeder normale User, der ein Symlink mit dem Namen "-i"
auf dieses Skript erzeugt, damit eine interaktive Shell mit Root-
Permissions erhalten, soferne das Shell-Script mit der Zeile
#!/bin/sh beginnt, denn dann wird die Shell mit dem Filenamen
als Parameter aufgerufen.
Es ist schon richtig, dass man niemals Shell-Scripts mit suid
versehen soll sondern immer nur uebersetzte Programme.
--
Hubert Partl pa...@mail.boku.ac.at
ZID BOKU Wien http://homepage.boku.ac.at/partl/
COMPVTOR ERGO SVM :-)
Wolfgang Dautermann
> Und was an einen Skript mit "fetch" als einzige Zeile als Inhalt
> gefährlich sein soll, sehe ich nicht ein.
Hast Du die beiden von mir angegebenen Webseiten gelesen?
Ciao, Wolfgang
Gerfried Fuchs
Dies ist keine einfache "Ich will auch noch meinen Senf dazugeben", sondern
dient einerseits zur Ergaenzung des ganzen und andererseits aus selbigem Grund
zur Aufname in die FAQ (deswegen die CC: an Dich, Jochen ;)
On Sat, 26 Jun 1999, Roland <e962...@stud3.tuwien.ac.at> wrote:
> Ich hab' mir ein Skript geschrieben um ein Programm etwas flüssiger zu
> betreiben:
>
> nice --10 Programm
>
> Das Skript gehört root.
> Die Rechte sind auf 755 gesetzt.
> Wenn das Suid-Bit gesetzt ist, dann sollte der Prozess alle Rechte des
> Besitzers (= root) bekommen, oder?
Nein. Und zwar aus folgendem Grund: Das Skript ist ein "Skript" und wird als
solches von der _shell_ ausgefuehrt, und nicht _selbst_! Wenn der Kernel ein
File sieht, das ausgefuehrt werden soll, ueberprueft es erst mal die ersten
paar Zeichen. Steht dort
#!
dann wird es als shell-skript erkannt, und der dahinter angegebenen shell als
_Parameter_ uebergeben, mitsamt den nachfolgenden Parametern zusaetzlich.
Insofern sollte es klar sein, dass hier ein suid-Bit bzw. sgid-Bit nicht
greifen kann.
> Jedenfalls kommt das folgende, wenn man das Skript als normaler Benutzer
> startet:
>
> nice: cannot set priority: Permission denied
>
> Warum?
Nun gibt es aber andererseits bereits ein suidperl - warum nicht also auch ein
suidbash oder aehnliches?
Aus ganz einfachen Sicherheitsueberlegungen: shell-Skripte bestehen im
Gegensatz zu perl-Skripten fast ausschliesslich aus Aufrufen von anderen
Programmen. Und hier liegt der Hund begraben: Diese Programme werden einerseits
ueber die $PATH-Variable gesucht, und andererseits meist durch andere
Environment-Variablen konfiguriert bzw. beeinflusst.
Diese kann allerdings _jeder_ User beliebig _aendern_! Und wer sagt Dir jetzt,
dass nicht jemand sich eine Dateil /tmp/boese/nice anlegt, und in dieses File
folgendes hineinschreibt:
---- /tmp/boese/nice ----
#!/bin/bash
rm -rf /
-------------------------
Anschliessend ein "export PATH=/tmp/boeses:/path/to/your/script" eingibt, und
dann Dein script startet?
Bloed gelaufen, sowas!
Klarerweise, bei so kurzen, einfachen trivialen Aufgaben ist das kein Problem,
das Skript sicher zu machen - doch sobald das Skript laenger und komplizierter
wird (und das sind root-Skripte meistens ;), wird es zu einer echten
Lebensaufgabe, dieses sicher zu bekommen.
Dieses Problem ist bei perl-Skripten nicht so stark gegeben, vor wird hier
auch einiges ueberprueft (u.a. wird ein "." in $PATH das Skript bald zur
Aufgabe bewegen....).
---- sodala, ich hoffe, bei der naechsten Frage diesbezueglich wird ein:
RTFFAQ @ http://alfie.ist.org/LinuxFAQ/ reichen *grins*
So long!
Alfie
--
What is mind? No matter.
What is matter? Never mind.
-- Thomas Hewitt Key, 1799-1875
Gerfried Fuchs
> Roland Seuhs <e962...@stud3.tuwien.ac.at> wrote:
> > Wenn root ein Skript schreibt, daß NUR ER ändern kann und das keine
> > Parameter als Kommandos ausführt, dann ist das kein Sicherheitsloch.
Du hast folgendes vergessen:
[X] das nur shell-builtin Kommandos ausfuehrt
... denn externe Kommandos _koennen_ und _werden_ durch Environment-Variablen
beeinflusst!
> Es gibt - wenn ich mich richtig an die FAQ von comp.unix.questions
> erinnere - noch ein anders Sicherheits-Risiko:
>
> Wenn es sein Shell-Script gibt, das ein suid-Bit gesetzt hat,
> dann kann jeder normale User, der ein Symlink mit dem Namen "-i"
> auf dieses Skript erzeugt, damit eine interaktive Shell mit Root-
> Permissions erhalten, soferne das Shell-Script mit der Zeile
> #!/bin/sh beginnt, denn dann wird die Shell mit dem Filenamen
> als Parameter aufgerufen.
Nur mit /bin/sh oder mit jeder beliebigen shell? Welche shell-Version? ;)
> Es ist schon richtig, dass man niemals Shell-Scripts mit suid
> versehen soll sondern immer nur uebersetzte Programme.
... und vor allem, es hat keinen Sinn, wie ich in
<slrn7nfls2...@skater.htu.tuwien.ac.at> schon erklaerte :)
So long!
Alfie
--
Drive defensively. Buy a tank.
Roland Seuhs
> > gefährlich sein soll, sehe ich nicht ein.
>
> Hast Du die beiden von mir angegebenen Webseiten gelesen?
>
Roland(der sich jetzt schämt);
P.S: Trotzdem finde ich daß sudo nur ein Notnagel ist.
P.P.S.: Aber jetzt hab' ich fetch trotzdem hingekriegt!
> Ciao, Wolfgang