[Redhat] Executable permissies in gebruikersdirectories

[BoXie]

Hallo,

Een security vraagstuk.

Stel ik geef een klant op een Linux webserver shell-access (hetgeen ik niet gauw zal doen .. maar toch). Hij kan dan files 'executable' permissies geven .. en zo bijvoorbeeld 'wget' in zijn directory zetten en uitvoeren. Wie weet ook wel IRC achtige dingen of mini-webservers draaien.

Dit lijkt me een groot securityprobleem. Dus mijn vraag is ... HOE kun je voorkomen dat gebruikers op (in dit geval) een webserver daemons draaien of programma's uitvoeren ? Voor zover ik weet bestaat er geen chmod-commando op een parent-dir die je verbiedt om executable rechten op files te zetten binnen deze directory ... toch ? Voor subdir's heb je dit zelfs nodig natuurlijk.

En zelfs binnen een chrooted shell zou je nog dingen als 'wget' aan de praat kunnen krijgen denk ik.

Is er een 'best-practise' om dit soort zaken het hoofd te bieden ?

[ Voor 17% gewijzigd door BoXie op 28-07-2005 01:03 ]

[jep]

Je kunt met bepaalde kernel patches zoals grsecurity wat van dit soort zaken instellen. Verder kun je er ook voor zorgen dat users geen toegang hebben tot je compilers. De executables zelf kunnen (denk ik) alleen door de kernel (/patch) worden gestopt.

Een firewall voor een bepaald userid (iptables kan dit) kan ook uitkomst bieden om netwerk activiteiten te limiteren.

[blaataaps]

Je kunt het filesystem met homedirectories mounten met de "noexec" optie, maar of het verstandig is om mensen die je zo weinig vertrouwt shell-access te geven.

[Boudewijn]

chroot + umask goed zetten (-X) + waarom zou chmod je in je chroot zetten? + kernel patch

zoiets zou ik dan doen. Verder ben ik het met blaataaps eens.

Maar even terug op hierboven:

is het niet mogelijk in een chroot chmod niet op te nemen? Als dan de rechten 'goed' staan kun je ze toch niet meer veranderen? (maybe heel erg low level wel)

[Coen Rosdorff]

Als je wil dat de mensen die je shell access geeft geen processen kunnen uitvoeren, wat hebben ze dan aan die shell?

[BoXie]

@Boudewijn:

Ik gebruik Plesk 7.5.3 op mijn webservers .. en daarin zit inderdaad een chrooted shell omgeving die je kunt aanzetten voor je klanten (en ALS ik aan iemand shell-access zou geven is het DIE chrooted shell .. met name omdat ze dan kunnen SFTP'en) chmod is daarin NIET opgenomen. Joepie .. dacht ik .... want via een tool als WinSCP kan ik gewoon bestandspermissies wijzigen en alsnog exec-rechten geven aan bestanden.

Wat bedoel je met umask op '-X' zetten ?

[BoXie]

little_soundman schreef op donderdag 28 juli 2005 @ 02:21:
Als je wil dat de mensen die je shell access geeft geen processen kunnen uitvoeren, wat hebben ze dan aan die shell?

Nou daar sta je nog van te kijken .. Shell kan ERG nuttig zijn om allerlei web-apps te installeren enzo (Gallery, Mambo etc .. ).

En ik bedoel met name dat ze geen EIGEN bestanden kunnen uitvoeren.

[ Voor 10% gewijzigd door BoXie op 28-07-2005 02:28 ]

[Boudewijn]

hoe install je dat?

juist ja een tarball.... die moet je untarren.
Dus moet je een tar executable hebben.

volgens mij is dat dus onafwendbaar. een chroot met alles eruit gesloopt op rm, cp, mv, vi, tar en nog wat zooi na lijkt mij het enige werkende.

[BoXie]

Hmm ok .. dus dat ik via WinSCP kan chmodden zonder dat er een chmod binary in de chrooted omgeving staat komt omdat een ander commando dit doet ? Ik zie een commando 'scp' en een '/usr/libexec/openssh/sftp-server' in de chroot-omgeving staan .... zorgen een van deze twee bijv. ervoor dat ik TOCH permissies kan veranderen via een SCP/SFTP client?