Bonjour,
Je viens demander votre avis expert parce que j'ai un petit souci. Je dois donner un accès ssh sur ma machine perso à qqun que je ne connais absolument pas (je sais, c'est balo, mais croyez moi je n'ai pas le choix). Je vais donc lui créer un compte utilisateur qui ne sera dans aucun groupe sauf le sien.
Mais cela ne l'empechera pas d'avoir accès en lecture à une bonne partie de ma machine (/, /etc, /home/*, ...)
Je pourrais changer les permissions de tout ces dossiers, mais ce serait fastidieux. En plus, si je fais un truc du genre chmod o-r sur des fichiers de configuration (appartenant a root, mais utilisés par des applications utilisateur), ca risque de me mettre une sacré pagaille dans mes applis.
L'idéal serait qu'il n'ait le droit de lire QUE son dossier home, et qu'il ne puisse même pas lister le contenu d'un autre dossier.
Existe-t-il un moyen simple de faire ce genre de choses ?
Merci pour votre aide !
P. Berger
Forum Linux.général Compte utilisateur avec droits TRES restreints
24
nov.
2010
# chroot
Posté par TortuXm . Évalué à 3.
Est-ce que ton utilisateur a besoin d'exécuter des commandes via ssh ou juste de lire et écrire des fichiers sur son $home ?
Si c'est juste pour du transfert de fichiers, tu pourrais aussi lui donner juste un accès à sftp par exemple, avec un chroot réalisé directement par ssh (cf sshd_config pour savoir comment faire ça si tu retiens cette solution)
Si ton utilisateur doit exécuter des programmes et qu'il n'a que quelques besoins spécifiques, tu dois pouvoir le chrooter avec seulement ces quelques programmes à disposition.
[^] # Re: chroot
Posté par Sébastien Koechlin . Évalué à 2.
http://it.slashdot.org/article.pl?sid=07/09/27/2256235
'chroot is not and never has been a security tool'
[^] # Re: chroot
Posté par neologix . Évalué à 6.
Et pourquoi OpenBSD fait tourner la plupart de ses démons sous chroot par défaut ?
Je sais qu'il est facile de sortir d'un chroot lorsque le processus est root, mais lorsqu'il tourne en tant qu'user (fork, chroot, setuid...), ça permet déjà d'éviter toute une classe d'exploits (failles dans programmes setuid, symlinks dans /tmp/, etc). C'est certes plus faible qu'une jail FreeBSD, mais c'est déjà un début. Après, si ton noyau est troué, c'est un autre problème...
[^] # Re: chroot
Posté par Fabien (site web personnel) . Évalué à 1.
[^] # Re: chroot
Posté par bubar🦥 (site web personnel) . Évalué à 3.
Loin de tout troll, peux tu expliquer un peu cette phrase :
un système linux (qui n'est pas un système à ranger dans la catégorie 'sécurisé')
En quelques mots, ce que tu en penses, et comment tu définis cette "catégorie sécurisée" (par exemple avec un pointeur vers des normes)
Merci.
ps : le patch grsec, tu trouves pas qu'il fait un peu "démo", au final ?
(que toute la partie "configuration système" devrait être sortie d'un patch "noyau" ?)
ps2 : ce sont des vraies questions, avec un peu de malice certes. Des pointeurs web de ta part suffiraient à combler ma curiosité. :-)
[^] # Re: chroot
Posté par neologix . Évalué à 5.
En quelques mots, ce que tu en penses, et comment tu définis cette "catégorie sécurisée" (par exemple avec un pointeur vers des normes)
Par exemple :
http://en.wikipedia.org/wiki/Evaluation_Assurance_Level
Après, il faut le prendre avec des pincettes, cela ne veut absolument pas dire qu'un système est sécurisé, c'est juste une certification qui dépend de certains critères...
Tu noteras que tous les GPOS sont au niveau EAL4.
Quant à la remarque sur Linux, tu peux la prendre dans le sens où la sécurité n'a jamais été un des buts premiers du noyau, qui est plutôt axé sur les performances. Par exemple, il n'y a pas par défaut de protection du type W^X, pas de protection des stacks, l'entropie pour l'ASLR est assez faible, pas d'access crontrol, etc. Il n'y a pas de mesure de sécurité pro-active, ce qu'essaie de corriger grsec.
Personnellement, je trouve dommage que les développeurs principaux ne s'intéressent pas plus à la sécurité, on a quasiment toutes les semaines des failles, et pas mal de failles qui permettent à un utilisateur de passer root...
ps : le patch grsec, tu trouves pas qu'il fait un peu "démo", au final ?
(que toute la partie "configuration système" devrait être sortie d'un patch "noyau" ?)
Comprends pas la question. Tu parles du RBAC ?
[^] # Re: chroot
Posté par TortuXm . Évalué à 2.
Bien sûr je suis complètement d'accord pour dire que chroot n'est pas la solution ultime à tous les problèmes et qu'il existera toujours des moyens pour "sortir" du chroot.
En fonction du problème, ça peut être la solution la plus simple pour générer un environnement "allégé" avec moins de risques de fausses manipulations.
[^] # Re: chroot
Posté par Gniarf . Évalué à 5.
ça (me) sert à bidouiller, installer, réparer, et même créer des systèmes Linux, sur le même disque ou depuis un autre
par exemple, après un chroot, une commande rpm ou apt-get ira mettre à jour le système chrooté, pas celui d'où tu as lancé la commande chroot
[^] # Re: chroot
Posté par TortuXm . Évalué à 1.
Au moment d'écrire le message, j'aurais dû penser à cette utilisation :)
# chroot
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 2.
Voici un lien qui peut t'aider:
http://www.majorxtrem.be/2009/04/24/chrooter-un-user-dans-un(...)
[^] # Re: chroot
Posté par Pierre Berger . Évalué à 1.
C'est vrai que je n'étais pas très précis sur les besoins de mon utilisateur :
- il doit pouvoir : lire et écrire dans son home
- compiler et executer des programmes java dans son home, killer la JVM si elle plante (ça arrive si rarement, ... :-) )
Je maitrise pas du tout le chroot, je vais me renseigner.
Merci encore pour le coup de main.
[^] # Re: chroot
Posté par TortuXm . Évalué à 4.
En effet, je ne suis pas sûr qu'il soit facile d'isoler le processus Java et ses dépendances. Et une fois ces dépendances mises à disposition dans le chroot, je ne suis pas sûr que la sécurité soit bien meilleure que sans le chroot, si tu intègres les 3/4 de ton système ;)
[^] # Re: chroot
Posté par Ecran Plat (site web personnel, Mastodon) . Évalué à 1.
[^] # Re: chroot
Posté par daimrod . Évalué à 2.
# autre possibilité: la machine virtuelle
Posté par pma . Évalué à 9.
Si tu pouvais lui interdire tous les répertoires sauf ~, il aurait des problèmes à exécuter les commandes de base n'ayant pas accès /bin. De même avec /etc, certains logiciels ne fonctionneraient pas ou utiliseraient la configuration par défaut. Donc il doit garder l'accès en lecture aux répertoires du système. Normalement, les modifications sont réservées à root, propriétaire de ces fichiers donc il ne peux rien y changer (et ne peux même pas lire /etc/shadow qui contient les mots de passe).
Tu peux lui barrer l'accès à ton répertoire ~ en lui en interdisant l'accès et la traversée de ce répertoire, il ne pourra alors pas descendre dans l'arborescence. Évidement, tu ne dois pas lui donner l'accès root/sudo.
Autre solution que le chroot: créer une machine virtuelle sur ta machine avec un ssh que tu rend accessible depuis l'extérieur. Il pourra y faire ce qu'il souhaite (accès root) mais n'aura pas accès aux systèmes de fichier et à la mémoire réels. (mais le chroot ou le sftp suffit peut être à tes besoins).
[^] # Re: autre possibilité: la machine virtuelle
Posté par marahi . Évalué à 2.
Si tu veux lui donner accès à certains documents seulement, alors tu pourras :
- créer un dossier où tu mettras des liens vers les documents
- restreindre les droits d'accès à ces fichiers/dossiers
- partager ce dossier avec la machine virtuelle en NFS (Virtualbox le fait très bien, très peu de config sous Linux)
- utiliser le bon paramétrage réseau pour la VM (ex. Bridged Networking dans Virtualbox) et éventuellement limiter la bande passante sur le périphérique réseau virtuel (avec wondershaper par exemple).
Comme ça, l'utilisateur sera dans Matrix tout en se croyant dans le monde réel.
# une piste
Posté par gaaaaaAab . Évalué à 1.
[^] # Re: une piste
Posté par Marc Quinton . Évalué à 1.
[^] # Re: une piste
Posté par deuzene (site web personnel) . Évalué à 2.
Ça se configure assez finement apparemment.
« Il vaut mieux mobiliser son intelligence sur des conneries que mobiliser sa connerie sur des choses intelligentes. »
# Shells restreints
Posté par X345 . Évalué à 2.
J'utilise pour ma part lshell ( http://lshell.ghantoos.org/ ) qui est extrêmement simple. Attention, cependant, même si tu utilises lshell, l'utilisateur à toujours accès à toute l'arborescence via SFTP. Tu peux l'utiliser conjointement avec MySecureShell (qui comme son nom ne l'explique pas du tout permet d'appliquer des restrictions au serveur SFTP) : voir http://sourceforge.net/projects/lshell/forums/forum/778301/t(...) . Pense également à ulimit pour éviter les attaques de type DoS. Dernière chose, ces deux derniers projets n'ont pas l'air d'avoir été vraiment testés/éprouvés, il a donc surement des failles de sécurité dedans.
Il existe également GNU Rush, qui a l'air plus puissant (peut-être plus securisé) : http://puszcza.gnu.org.ua/software/rush/manual/html_section/(...)
Sinon, comme dit plus haut il y a l'option chroot de SSH ou les jails de type OpenVZ/Vserver/LXC qui présentent à mon avis l'inconvénient d'être plus lourds à mettre en place (et surement overkill...).
# Chrooter le SFTP
Posté par BlueWhisper . Évalué à 1.
Subsystem sftp internal-sftp
Match Group untrusted
ChrootDirectory %h
ForceCommand internal-sftp
Ainsi, les utilisateurs du groupe untrusted sont chrootés dans le dossier personnel (%h), et ne peuvent que faire du sftp.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.