[RedHat 7.1]Home directory als root laten

[pkouwer]

Ik heb een linux-machine opgezet met o.a. een home-dir. Als gebruikers inloggen komen ze in deze directory. Logisch. Nu wil ik ze in deze home-dir houden, dus pietje blijft in /home/pietje/ en klaasje in /home/klaasje.

Ik heb al wel op google gezocht , maar kan niet vinden wat ik wil. Ik wil voorkomen dat ze een dir. hoger komen /home en door kunnen gaan naar bv /usr, /, of /home/andereuser.

Deels kan ik het oplossen met chmod, maar verder kom ik niet. Ik wil niet dat klaasje ziet dat pietje een home dir heeft. Dus /home/pietje is de root.

(valt het nog te snappen ?)

[Rac-On]

ja, en ik weet dat het onder debian met chroot kan. daarmee simuleer je een root dir. Moet je er wel aan denken alle benodigde scripts and libraries in de home dir erbij te zetten.

Edit:
Het kan ook gewoon onder RedHat.
Heb even een HOWTO voor je gevonden:
http://www.redhat.com/mir...TO/Chroot-BIND-HOWTO.html

Ander kun je ff op www.deja.com zoeken naar +chroot +redhat dan vind je wel het 1 en ander

[ Voor 47% gewijzigd door Rac-On op 11-03-2004 08:48 ]

[CyBeR]

Ja, dat valt te snappen. Het is namelijk de eerste vraag die mensen stellen die voor het eerst een multi-user systeem neerzetten waar daadwerkelijk meerdere van gebruikmaken. Het dichtst bij kun je komen met een restricted shell. Man bash, zoek naar de -r optie.

Een chroot is niet handig. Je moet dan namelijk alle utilities (bash, ls, rm, weetikhet) ook in die homedir zetten. Die staan namelijk in /bin en /usr/bin, en daar kun je vanuit een chroot niet bij.

Overigens vind ik het vreemd dat deze vraag zo vaak gesteld wordt. Je vertouwt mensen wel genoeg om ze een inlogaccount te geven, maar daar mogen ze dan vervolgens niets mee? Als het alleen voor webspace is, laat ze dan lekker alleen ftp access hebben.

[pkouwer]

het gaat om en stukje prive-ruimte, ook een beetje om linux te leren
Als het zo vaak gevraagd wordt, waarom staat het dan niet bij de faq. Hoe kan ik dit nu oplossen als chroot niet handig is ? Wat is dan wel de juiste werkwijze ?

[Rac-On]

CyBer, je hebt gelijk dat je idd een boel dingen moet gaan verplaatsen (softlink werkt ook als je je chroot goed insteld) maar op die manier heb je wel 100% controle over wat je users kan/mag en wat niet. Bovendien simuleer je hiermee een filesysteem waar /home/user je absolute root is, en waar je dus op geen enkele manier buiten komt.

Een bash -r is niet handig. Hiermee maak je een simpel commando als cd onmogelijk. ook de pipe | en de redirect > werken niet meer.

Bovendien schakeld een restricted bash alle restricted opties uit op het moment dat er een shell script wordt gedraaid.

code:

       It behaves identi­cally to bash with the exception that  the  following  are
       disallowed or not performed:

       changing directories with cd
       [...]
       When  a command that is found to be a shell script is exe­
       cuted (see COMMAND EXECUTION above), rbash turns  off  any
       restrictions in the shell spawned to execute the script.
       [...]

Overigens is het met chmod ook mogelijk om directories unbrowsable te maken voor normale users. Een user kan alleen de inhoud van een directory zien als hij/zij er read rights op heeft (in debian dan). Daarmee zou je ook wel het 1 en ander onzichtbaar kunnen maken.

In principe kan het niet zoveel kwaad als een gewone user een beetje door je filesystem kan browsen.

Ook en mogelijkheid is om een secure kernel te draaien. Die is er op gemaakt om een user zo min mogelijk rechten te geven...

[ Voor 22% gewijzigd door Rac-On op 11-03-2004 11:35 . Reden: foute gefixed thanx to icemanx ]

[Robtimus]

rac-on schreef op 11 maart 2004 @ 10:59:
Overigens is het met chmod ook mogelijk om directories unbrowsable te maken voor normale users. Een user kan alleen de inhoud van een directory zien als hij/zij er execute rights op heeft (in debian dan). Daarmee zou je ook wel het 1 en ander onzichtbaar kunnen maken.

Volgens mij vergis je je. Ze kunnen als hij/zij er execute rechten op heeft alleen de directory ingaan. Een ls oid zal daarna echter aangeven dat je daar geen rechten op hebt. Pas als een dir zowel readable als executable is kan je er gewoon in.
Als je gewoon alle home dirs chmod op 700 kan alleen de user (en root natuurlijk) erin. Gebruikers kunnen dan wel zien welke andere users er zijn, maar kunnen verder niet bij hun files.

In principe kan het niet zoveel kwaad als een gewone user een beetje door je filesystem kan browsen.

Volledig mee eens, daar leer je juist van als gebruiker. En je mag toch niks verkloten

[Rac-On]

Je hebt gelijk. Ik bedoelde (excuus dat ik onduidelijk was) dat je met execute right erin mag, maar dat je read access nodig hebt om een ls te doen.

Als je duss en chmod 611 doet op /home, dan kunnen je users wel gewoon hun home dir in en uit, maar kunnen ze niet de homedirs van andere users zien. Op die manier kan een user geen ls doen in /home, en dus niet zien welke andere users er zijn.

Eventueel kan je dan nog een chmod 750 doen op alle homedirs, zodat een user zelf alstie de username van een andere gebruiker weet, niet in zijn/haar homedir kan.

Volgens mij ben je er dan wel?

[ajvdvegt]

Let op dat je met chroot enkel beginners tegenhoudt: How to break out of a chroot() jail.

[Rac-On]

ajvdvegt schreef op 11 maart 2004 @ 12:04:
Let op dat je met chroot enkel beginners tegenhoudt: How to break out of a chroot() jail.

hmzz, heb je het stuk wel gelezen? Er staat:

It is then a matter for the user to gain root access via security holes on the box running the web server. Whilst this is outside the topic of the document, an attacker could make use of application programs which are setuid-root and have security holes within them. In a well maintained chroot() area such programs should not exist.

Oftewel, eerst een linux doos root'en. Ik weet niet wat jij onder beginner verstaat, maar het lijkt me hierbij niet van toepassing. Als je een homedir chroot voor een normale user op de min of meer basic/standaard manier, heeft ie alleen toegang tot de normale bash commando's als cd, rm e.d. Het lijkt me niet dat je een users die je wil chrooten, toegang heeft to suexe oid?

Als een user root access heeft/kan krijgen, dan is alles toch hopeloos. Een chroot is wel degelijk een veilige applicatie, mits in hande van een competente systeembeheerder. Als je die niet hebt, dan is je linux doos niet veilig te krijgen.

[ajvdvegt]

Ik heb het artikel zeker wel gelezen, en het geeft alleen maar aan dat je 'makkelijk' uit een chroot() omgeving kan breken. Dan ben je uiteraard niet meteen root, maar je gebruikt een chroot omgeving om ervoor te zorgen dat gebruikers niet op je hele systeem rond kunnen neuzen. En dat kunnen ze nu juist net wel als ze eenmaal uit de chroot() omgeving zijn gebroken.

Het al dan niet verkrijgen van root-rechten staat hier helemaal los van m.i..

[Rac-On]

Dan heb je toch (sorry, no flame intended) niet goed gelezen. Er staat dat je makkelijk uit een Chroot kan breken, Als je op de een of andere manier root rechten hebt .

En dazz wezelijk wat anders. Als je root bent, kun je alles op een systeem, zonder enige beperking (tenzij je, zoals ik al aangaf, een secure kernel draait).

Een chroot is dus gewoon veilig, zolang je er geen root-user mee tegen probeert te houden.

En dan is het dus aan de systeembeheerder om te voorkomen dat iemand op de een of andere manier onbedoeld root-rechten krijgt.

[ajvdvegt]

Je hebt gelijk, sorry! Ik had het wel gelezen, maar toch te snel en het dus verkeerd begrepen. En ik was absoluut niet van plan een flame uit te lokken hoor, ik wees enkel op een potentieel gevaar.

[Wilke]

ajvdvegt schreef op 11 maart 2004 @ 12:52:
Ik heb het artikel zeker wel gelezen, en het geeft alleen maar aan dat je 'makkelijk' uit een chroot() omgeving kan breken. Dan ben je uiteraard niet meteen root,

Nee, dat zegt het artikel niet. Om uit een chroot omgeving te breken moet je gewoon die machine hacken (dus root verkrijgen via een exploit of whatever). Dat artikel bevat onzin:

Whilst chroot() is reasonably secure, a program can escape from its trap. So long as a program is run with root (ie UID 0) privilages it can be used to break out of a chroot()ed area. For a user to do this, they would need access to:
- C compiler or a Perl interpreter
- Security holes to gain root access

Dat tweede is natuurlijk waar, maar dat is altijd zo, dus dat heeft niets met het al of niet chrooted zijn van een machine te maken. Het eerste: ik weet niet hoor, maar compilers en Perl draaien bij mij echt niet setuid root, en ik zou ook niet weten waarom dat wel het geval zou moeten zijn.
Natuurlijk zijn er wel andere setuid programma's die misschien exploitable zijn, maar dan is het dus de taak van de admin om te zorgen dat deze a. niet geinstalleerd zijn of b. niet bereikbaar zijn vanuit de chroot()-jail.

Dus ik weet niet hoe die gasten denken dat je vanuit een chroot-jail een setuid-programma gaat opstarten dat buiten die jail staat, lijkt me vrij tricky (lees: onmogelijk). Als je een security flaw in Linux (de kernel) weet, dan kom je er natuurlijk wel in, maar dan wordt je dus root en kun je sowieso alles. Sja...

[igmar]

ajvdvegt schreef op 11 maart 2004 @ 12:04:
Let op dat je met chroot enkel beginners tegenhoudt: How to break out of a chroot() jail.

Dit verhaal is een beetje erg overtrokken : Die jail breaks zijn alleen mogelijk indien je root permissies hebt. Verder zijn de in dat artikel genoemde methoden vrij simpel tegen te gaan dmv grsecurity.

[Rac-On]

@ PKOUWER:

Is het nu een beetje duidelijk wat je opties zijn? Als je je complete filesystem af wilt schermen en van de homedir van de user de root wilt maken, zul je dus een chroot moeten/kunnen gebruiken Zie mijn eerste post voor een linkje naar de howto rac-on in "[RedHat 7.1]Home directory als root late...".

Als je alleen maar de homedirs onzichtbaar/onbereikbaar wilt maken voor andere users, kun je met een chmod af (zie rac-on in "[RedHat 7.1]Home directory als root late...")

Ik hoop dat je zo genoeg opties hebt om te bereiken wat je wilt

[pkouwer]

hartelijk dank voor de reacties, ik zal er eens naar kijken. Hoewel ik noob ben op het gebied van linux, zijn dit leuke dingen om uit te zoeken.

Ik kom hier zeker op terug !

[mvdejong]

Je moet eens kijken naar de "restricted" versies van de gangbare shells.
Ik weet dat er een "rsh", "rcsh", en "rksh" versies bestaan (deze "rsh" is de "restricted (Bourne) shell", niet de "remote shell" die ook wel "remsh" wordt genoemd).

Misschien beperkt het te weinig voor je, misschien teveel.

[Verwijderd]

Je hebt een beetje een kip/ei probleem. Een standaard user mag niet zo gek veel op een standaard systeem. Hij moet om te kunnen oefenen (scriptjes bouwen, beetje prutsen) toch bij de executables in /bin, /usr/bin en /usr/local/bin kunnen komen. Of je kopieert deze naar een /bin in een chroot.

Kijk verder wat een gewone user kan uitspoken, maar wat jij eigenlijk niet wilt.

Zo kan klaasje op de meeste systemen zien dat pietje inderdaad een home directory heeft, maar daar komt klaasje toch wel achter als hij een cat /etc/passwd doet. Hij kan echter niet kijken wat er in de homedir van pietje staat.