Archiv verlassen und diese Seite im Standarddesign anzeigen : User bestimmte kommandos aus /usr/bin nicht erlauben.
Hallo,
ich habe einen User x, dem ich die Shell /bin/rbash gegeben habe, damit er wirklich nur in seinem HOME Verzeichnis bleibt. So nun möchte ich ihm gerne nen paar Kommandos aus seinem PATH nicht ausführen lassen dürfen, wie php, sudo und so kritische Sachen halt? Wie könnte man das am besten anstellen?
Gruß
Ändere doch die Rechte bzw. Gruppen der Binarys.
Ist nen bissel Fehleranfällig denke ich, vorallem bei so Sachen wie PHP-Cli...
Guten Morgen,
Gegenfrage: Was möchtest du dem Nutzer denn erlauben? Ich würde an deiner Stelle über einen 'chroot jail' nachdenken, den ich für sinnvoller ( wenn auch aufwändiger zu realisieren ) halte.
Grund: Aus einer rbash lässt sich bereits mit vi auf einfachste Art und Weise ausbrechen [1]
-hanky-
[1] http://www.softpanorama.org/Scripting/Shellorama/restricted_shell.shtml
Übrigens befinden sich doch in /bin und /usr/bin keine wirklich kritischen Kommandos. Was du aber noch machen könntest, ist das Entfernen der Sticky-Bits (http://de.wikipedia.org/wiki/Sticky_Bit) bei einigen Binarys.
Unter /bin und /usr/bin liegen keine administrativen Kommandos. Wenn da dennoch Dinge drinliegen, die dein User nicht ausführen darf, dann solltest du ihn in ein Chroot einsperren.
Unter /bin und /usr/bin liegen keine administrativen Kommandos. Wenn da dennoch Dinge drinliegen, die dein User nicht ausführen darf, dann solltest du ihn in ein Chroot einsperren.
Aber alleine der Punkt, das er sudo ausführen kann (Ubuntu Dapper Drake), ist meines erachtens schon gefährlich, auch wenn er das PW evtl. net hat! :) Aber werde ihn wohl in ein Chroot einbinden
Rain_maker
03.10.06, 11:08
Aber alleine der Punkt, das er sudo ausführen kann
Dann verbiete ihm das, das geht viel einfacher.
Nicht jeder User darf automatisch unter Ubuntu "sudo" anwenden (IIRC ist es die Gruppenzugehörigkeit zu wheel, *Ohne Gewähr* bin jetzt zu faul zum suchen).
Greetz,
RM
Sudo kann man sehr schön einrichten und sowas auch verhindern. man sudo ist dein Freund. :)
Oder Du änderst die PATH-Variablen des Users X. Z. B. kannst Du /bin rausnehmen und ihm /opt/binx zuweisen, wohin Du die Programme linkst, die er aufrufen darf.
Nur so ne Idee.
gadget
Wenn man es dem User wirklich verbieten will und es nur ein paar progs sind reicht auch
chown boeser_user /bin/kritische_datei
chmod u-rwx /bin/kritische_datei
Oder Du änderst die PATH-Variablen des Users X. Z. B. kannst Du /bin rausnehmen und ihm /opt/binx zuweisen, wohin Du die Programme linkst, die er aufrufen darf.
Nur so ne Idee.
gadget
Die bringts doch nicht wirklich. Er kann ja entweder den vollen Pfad zum Binary eingeben oder einfach in seine .bashrc einen eigenen PATH eintragen.
MfG ako
Die bringts doch nicht wirklich. Er kann ja entweder den vollen Pfad zum Binary eingeben oder einfach in seine .bashrc einen eigenen PATH eintragen.
MfG ako
waere eigentlich ein Shellscript mit 2 -3 hard codierten Pfaden als Shell
angreifbar? Upload's sollten vielleicht verboten sein. :)
caspartroy
04.10.06, 12:50
Wenn man es dem User wirklich verbieten will und es nur ein paar progs sind reicht auch
chown boeser_user /bin/kritische_datei
chmod u-rwx /bin/kritische_datei
was genau soll denn das bringen?
was genau soll denn das bringen?Das User "boeser_user" Datei "kritische_datei" nicht mehr ausführen/lesen/beschreiben kann..
caspartroy
04.10.06, 16:31
Das User "boeser_user" Datei "kritische_datei" nicht mehr ausführen/lesen/beschreiben kann..
das ist ja prima... jedenfalls solange er nicht chmod u+rwx eingibt ;-)
das ist ja prima... jedenfalls solange er nicht chmod u+rwx eingiebt ;-)Hmm, auch wieder wahr!:rolleyes: Aber mit ner seperaten Gruppe würde es gehen! ;)
Die bringts doch nicht wirklich. Er kann ja entweder den vollen Pfad zum Binary eingeben oder einfach in seine .bashrc einen eigenen PATH eintragen.
MfG ako
Das ist so wahr, dass es mir schon fast unangenehm ist...
gadget
Was mir gerade einfällt: Wenn man dem User die Shell /bin/rbash zuteilt ist die Shell "restricted" und er darf mitunter folgendes nicht (aus "man bash"):
· changing directories with cd
· setting or unsetting the values of SHELL, PATH, ENV, or BASH_ENV
· specifying command names containing /
Das willst du aber nicht für Befehle unter /usr/bin oder /bin machen. Dafür ist das UNIX Rechtesystem zu unflexibel. SELinux wäre wohl die Lösung.
Hi!
das ist ja prima... jedenfalls solange er nicht chmod u+rwx eingibt ;-)
chown boeser_user /bin/chmod /lib/ld-*.so; chmod u-rwx /bin/chmod /lib/ld-*.so ;)
Gruß
fuffy
...Sehr gut!! Danke! :cool:
caspartroy
09.10.06, 22:52
Hi!
chown boeser_user /bin/chmod /lib/ld-*.so; chmod u-rwx /bin/chmod /lib/ld-*.so ;)
Gruß
fuffy
nette idee, aber käse...
ein chmod programm ist schnell gemacht, und wenn der user nicht mehr ld-*so ausführen kann, kann er gar nichts mehr machen.
im allgemeinen ist ld*.so für alle ausführbar.
als ich mich das letzte mal damit beschäftigt habe (ist ne weile her...), war chroot auf einer extra partition (nosuid usw) das kleinste übel, rbash hält nur computer unerfahrene auf. zu chroot gibts gute howtos.
selinux wäre eine option, aber nicht ganz einfach, gleichzeitig müsste sichergestellt werden, dass uploads nicht gefährlich werden, d.h. dass unter anderem chcon und chmod dem user nicht zur verfügung stehen.
wer selinux nutzen kann, stellt aber im allgemeinen keine solchen fragen ;-)
Hi!
nette idee, aber käse...
Das war auch nicht erst gemeint. Für so etwas gibt es chroot oder Jails.[/QUOTE]
Gruß
fuffy
Frage am Rande: Wie kann ich das "schnell gemachte chmod Programm" dann ohne chmod ausführbar machen? Ach ja, wir nehmen an, umask (und nen Compiler?) könnte man ebenfalls nicht ausführen.
Hi!
Frage am Rande: Wie kann ich das "schnell gemachte chmod Programm" dann ohne chmod ausführbar machen?
Das brauchst du gar nicht. /lib/ld-linux.so.2 ./chmod funktioniert auch ohne Executable-Flag. Die Datei chmod muss in diesem Fall nur für dich lesbar sein und das ist sie eh, da du sie angelegt hast. Wenn du umask 777 setzt, kannst du gleich den Benutzer löschen. ;)
Gruß
fuffy
Powered by vBulletin® Version 4.2.5 Copyright ©2024 Adduco Digital e.K. und vBulletin Solutions, Inc. Alle Rechte vorbehalten.