Hoe geef ik "speciale" rechten aan een user/folder voor ssh?

[Yzord]

Mijn vraag
...

Ik wil iemand toegang geven tot een server om iets op te laten lossen (implementatie van 2FA in PHP files), maar ik wil hem geen sudo rechten geven, omdat hij dat naar mij idee niet nodig heeft.

Ik zou graag willen dat als hij via ssh/sftp inlogt in de map terecht komt waar hij in mag werken, maar niet kan navigeren door de rest van de server. Ik weet hoe ik een user rechten kan geven op een map, maar daarmee kan hij wel door de rest van het file system "surfen". Ik heb al naar chroot gekeken, maar dat vind ik nogal een zware "oplossing" ervoor. Dat moet toch ook gewoon mogelijk zijn met specifieke rechten uitdeling aan een user?

Relevante software en hardware die ik gebruik
...

Linux, ssh

Wat ik al gevonden of geprobeerd heb
...

Heb wat met rechten zitten stoeien, maar elke keer kon ik gewoon door het file system surfen. Chroot werd me aanbevolen, maar om nu een speciale file system in de /var/www/html folder aan te maken is ook weer zoiets.

[Blokker_1999]

Chroot op zich was een optie geweest, maar betwijfel in dit geval of het goed gaat komen:

All components of the pathname must be root-owned directories that are not writable by any other user or group. After the chroot, sshd( changes the working directory to the user's home directory.

Dat je nog in je fs kan navigeren komt door de rechten op de gebruiker "other". En hoewel je die volledig zou kunnen uitschakelen is dat zeker niet altijd de beste oplossing.

Geen idee eigenlijk hoe haalbaar het hier gaat zijn om met ACLs te werken. Dan zou je een deny kunnen zetten voor die ene gebruiker met behulp van ACL op je hele bestandssysteem behalve voor de folder(s) waar hij in mag komen.

[Hero of Time]

Dit is allemaal te regelen via SFTP software zoals vsftpd, maar ook OpenSSH heeft deze optie. Er zijn zoveel tutorials online te vinden, dat ik het echt vreemd vind dat je dit vraagt eigenlijk. Een chroot is wel vereist, maar ik heb via de tutorials nooit een hele 'jail' moeten maken met /dev/ nodes etc. Nooit gezien ook. Enige is dat de map waar je in komt van root is (denk aan /var/www) en de submap kan je pas wat mee doen (dus /var/www/html).

[ddkiller0900]

Je zou ook eens kunnen kijken naar jailkit. Dan kan je zelfs aangeven welke commando's beschikbaar zijn binnen de chroot. Let er wel op dat je de benodigde libraries beschikbaar maakt.

[Rainmaker]

Hero of Time schreef op donderdag 28 januari 2016 @ 19:34:
Dit is allemaal te regelen via SFTP software zoals vsftpd, maar ook OpenSSH heeft deze optie. Er zijn zoveel tutorials online te vinden, dat ik het echt vreemd vind dat je dit vraagt eigenlijk. Een chroot is wel vereist, maar ik heb via de tutorials nooit een hele 'jail' moeten maken met /dev/ nodes etc. Nooit gezien ook. Enige is dat de map waar je in komt van root is (denk aan /var/www) en de submap kan je pas wat mee doen (dus /var/www/html).

En dan type je "vi index.php" en krijg je "command not found".

Kun je de externe niet gewoon een copy van de source files geven?

Wat staat er uberhaupt nog op die server anders dan PHP? Maakt het echt uit als die gebruiker door het fs heen kan bladeren?

Zit te denken om hem in een selinux context te zetten. Daarmee moet je dit af kunnen vangen. Maar is vrij veel moeite. Ga eerst eens na hoe erg je dit nu echt nodig vind.

[defusion]

Waarom zou shell toegang uberhaupt nodig zijn?
gewoon vsftpd met chroot. bewerken kan gewoon op de eigen pc.

[Hero of Time]

Rainmaker schreef op zaterdag 20 februari 2016 @ 10:51:
[...]


En dan type je "vi index.php" en krijg je "command not found".

Kun je de externe niet gewoon een copy van de source files geven?

Wat staat er uberhaupt nog op die server anders dan PHP? Maakt het echt uit als die gebruiker door het fs heen kan bladeren?

Zit te denken om hem in een selinux context te zetten. Daarmee moet je dit af kunnen vangen. Maar is vrij veel moeite. Ga eerst eens na hoe erg je dit nu echt nodig vind.

Ehm, wat? Waarom zou je in een sftp-subsysteem vi aan moeten roepen? Het is niet voor niets SFTP. Je geeft de gebruiker natuurlijk geen geldige shell. Scp en sftp moet 't doen en that's it. Dan gooi je via bijvoorbeeld FileZilla of WinSCP of Cyberduck de boel op de server.

Het hele idee van een jail is dat men niet zomaar vanalles kan uitvoeren. Dan wil je ook niet heel /usr/bin vrijgeven voor ze.

[MAX3400]

Yzord schreef op donderdag 28 januari 2016 @ 18:52:
Mijn vraag
...

Ik wil iemand toegang geven tot een server om iets op te laten lossen (implementatie van 2FA in PHP files), maar ik wil hem geen sudo rechten geven, omdat hij dat naar mij idee niet nodig heeft.

Afgezien van de oplossingen van anderen (zoals een jail maken met vsftpd); op het moment dat iemand een PHP-file mag/moet bewerken in een (live) omgeving, is toch sowieso je hele vraagstelling overbodig qua "security"? De persoon heeft toegang tot de files die nodig zijn om te connecten naar, bijvoorbeeld, je database maar ook redirects/rewrites van/naar andere files/directories.

Is het niet veel slimmer (maar meer werk) om van je /var/www een clone te trekken, deze aan te bieden aan de developer en daarna zelf uit te vogelen in welke files welke veranderingen zijn gemaakt? Ervanuitgaande (en dat lees je ook wel een beetje) dat de developer net zo goed/slecht is als jij met PHP

[DJMaze]

En hoe kan iemand een 2FA probleem oplossen zonder debugging?
Als jij geen vertrouwen in mij hebt als ontwikkelaar zou ik je opdracht niet aannemen.

In plaats daarvan zou ik je een geheimhoudingsovereenkomst aanbieden waarin alles is geregeld.
En ik wil een kopie van de VC (versiebeheer zoals Mercurial, Git, SVN, CVS, etc.).
Vervolgens werk ik in de VC, commit mijn wijzigingen en geef die dan terug.
Uiteraard is een database met dummy data ook belangrijk (dus geen kopie van de live omgeving).
Is er geen VC dan kan ik die ook voor je opzetten (uurtje factuurtje).
Er is dus totaal geen toegang nodig.

Het probleem moet je dus ergens anders oplossen, niet op de server.

[Ultraman]

Beknopt de stappen:
User aanmaken, met als homedir een dir net onder de webroot instellen, waarvan root de eigenaar is.
Bijv: apache/nginx serveert uit /var/www/www.mijnsite.nl, dan stel je als homedir /var/www waarvan root de eigenaar is.
Vervolgens in OpenSSH config voor die user een "ChrootDirectory" instellen.
Met ForceCommand internal-sftp zou je het ook nog SFTP only kunnen maken zodat er geen shell access is.

Die user komt na het inloggen in /var/www terecht en kan niet hoger in de boom komen.

Wat je ook zou kunnen doen is een normale homedir gebruiken. /home/user
root eigenaar maken van die directory (chown root:root /home/user)
De user daarin vast zetten met de ChrootDirectory in sshd_config.
Je webroot verplaatsen naar /home/user/webroot.
Zelfde effect.

Stukje documentatie vanaf de Arch wiki hierover: https://wiki.archlinux.org/index.php/SFTP_chroot

[ Voor 17% gewijzigd door Ultraman op 20-02-2016 11:48 ]

[Thralas]

Rainmaker schreef op zaterdag 20 februari 2016 @ 10:51:
Kun je de externe niet gewoon een copy van de source files geven?

Wat staat er uberhaupt nog op die server anders dan PHP? Maakt het echt uit als die gebruiker door het fs heen kan bladeren?

Dit is een mooie samenvatting van het probleem. Waarom is het zo'n probleem als iemand door je filesysteem kan wandelen? Los dat op, al het andere eindigt al snel in een schijnoplossing.

Ultraman schreef op zaterdag 20 februari 2016 @ 11:45:
Vervolgens in OpenSSH config voor die user een "ChrootDirectory" instellen.

Die user komt na het inloggen in /var/www terecht en kan niet hoger in de boom komen.

En dan geef je diezelfde user de mogelijkheid om willekeurige PHP-code uit te voeren. Zonder chroot. En dan ben je weer terug bij af.

SFTP chrooten is alleen zinnig als je echt enkel 'dode' storage aanbiedt.

[Ultraman]

Thralas schreef op zaterdag 20 februari 2016 @ 11:51:
En dan geef je diezelfde user de mogelijkheid om willekeurige PHP-code uit te voeren. Zonder chroot. En dan ben je weer terug bij af.

Ik was in de veronderstelling dat er een ontwikkelaar/oplosser juist met PHP code aan de slag moest om 2-factor authentication te gaan maken?

Als het absoluut niet op die machine mag, dan moet de ontwikkelaar een kopie van de webroot van die website krijgen. En dan kan hij/zij het op zijn eigen machine implementeren. Hoef je ook niet te kloten met toegang.

[ Voor 33% gewijzigd door Ultraman op 20-02-2016 11:55 ]

[Thralas]

Ultraman schreef op zaterdag 20 februari 2016 @ 11:52:
[...]
Ik was in de veronderstelling dat er een ontwikkelaar/oplosser juist met PHP code aan de slag moest om 2-factor authentication te gaan maken?

Ik ook. Maar dan heeft chrooten van de user account dus geen zin, omdat je met PHP niet chrooted bent (en waarschijnlijk ook de apache user).

En dat is dan puur de technische kant van het verhaal, want het scenario ansich is enigzins vreemd (zoals hierboven reeds meermaals is opgemerkt).

[Hero of Time]

Mensen, mensen, het topic is bijna een maand geleden geopend en de TS heeft niet eens gereageerd. Ga nou niet met allerlei dingen komen. De TS heeft het misschien al op een andere manier opgelost of iemand anders heeft 't voor 'm gedaan. Laten we nou eerst eens z'n reactie afwachten.