Discussion :

[kevin066]

Bonjour à tous,
Je dispose d’un serveur Linux en version RedHat 8 j’aimerais trouver une solution pour créer un compte qui accède à cet environnement uniquement en lecture sans aucune action possible de sa part.
Comme nous savons tous, sur Linux tout est fichier, et les droits sont positionnés sur les fichiers.
Mais je pensais à SELinux que je n’ai jamais implémenté.
Peut-être créer un contexte ALL et un autre contexte READ.
Je cherche dans la littérature, mais rien ne me semble évident.
Qu’en pensez-vous ?

[papajoker]

bonjour

qui accède à cet environnement uniquement en lecture sans aucune action possible de sa part.

je n'ai pas compris ce que tu désires exactement, un compte par défaut n'a que son $HOME en écriture.
- Tu peux créer simplement un user sans HOME, il ne pourra donc rien modifier
- Tu peux créer un user sans shell (/etc/passwd) : ne peut accéder qu'à quelques services

"Accéder à un serveur linux" est vague.

[kevin066]

Merci beaucoup pour ta réponse,
Je souhaite créer un compte qui accède à l’OS uniquement pour consulter, mais sans pouvoir modifier.
Tu veux dire je crée un compte lambda sans Home Directory et sans Shell et ce compte ne pourra, par exemple, que consulter les fichiers même ceux qui ont des droits sur «*other*», et avoir un droit très restreint sur quelques services ?

[binarygirl]

Mais l'utilisateur va se connecter comment ? En SSH à distance ? Ou se logger physiquement sur un PC ?
Pour quoi faire ? Si vous définissez mieux ce qu'il doit pouvoir faire et ne pas faire, alors on verra mieux quelle est la meilleure approche.
Si l'utilisateur n'a pas de shell, il ne pourra même pas se logger en console (en SSH en tout cas), mais c'est intéressant pour faire du SSH tunneling par exemple.
Même un utilisateur lamba (non privilégié) a accès à d'autres choses que son répertoire personnel, par exemple les logs (dans /var/log) et même beaucoup d'autres répertoires, même si les droits en écriture ou lecture sont plus restreints.

[kevin066]

L’Utilisateur en question se connectera en SSH ou en Telnet via un client Putty par exemple.
L’idée c’est qu’il puisse se balader sur le serveur, sans pouvoir modifier les fichiers, juste consulter.
Pour le reste (services ou autre) ce n’est pas capital, idéalement aucune action, mais le plus important c’est qu’il ne puisse pas modifier les fichiers du serveur.
Voilà mon besoin.

[chrtophe]

Tu créé un utilisateur, et tu fais un chmod -w sur le dossier /home/nomèutilisateur

Tu pourras te loguer dessus mais ne pourras pas écrire dedans
Attention aux effets de bord, exemple si tu lances nano tu auras un message comme quoi il ne peut pas créer le fichier .nano mais après ça fonctionne avec les limites que rien ne peut être écrit dans le compte.
Pour des fichiers partagés, c'est le propriétaire de ceux-ci qui devra gérer le partage.

[kevin066]

Merci.
J’ai testé : en effet les fichiers du type
- rwx rw- rw-
ne peuvent plus être modifié par ce compte.
En revanche, en faisant un «*echo*» j’arrive rajouter une ligne dans le fichier.

[Sve@r]

Bonjour

J’ai testé : en effet les fichiers du type
- rwx rw- rw-
ne peuvent plus être modifié par ce compte.

Bizarre puisque les fichiers ont le droit "w" actif, les fichiers sont modifiables. Qu'est-ce qui te fait dire qu'ils ne le sont pas?

En revanche, en faisant un «*echo*» j’arrive rajouter une ligne dans le fichier.

Ben voilà, ils sont donc bel et bien modifiables.

Pour en revenir à la question de départ, à savoir un compte non modifiable il te suffit de le donner à root => chown -R root /home/compte_en_question. Puis de positionner tous les dossiers à 755 => find /home/compte_en_question -type d -exec chmod 755 {} +. Puis de rajouter le droit "r" et d'enlever le droit "w" aux fichiers => find /home/compte_en_question -type f -exec chmod a+r,go-w {} + (pourquoi passer par l'ajout et la suppression au lieu d'écrire simplement "chmod 644"? Juste pour préserver le droit "x" s'il est positionné => si un fichier est un exécutable, il doit rester exécutable)
De là, l'utilisateur pourra y entrer, s'y promener, lire ce qui s'y trouve mais ne pourra rien modifier.

Tu créé un utilisateur, et tu fais un chmod -w sur le dossier /home/nomèutilisateur

Tu pourras te loguer dessus mais ne pourras pas écrire dedans

Déjà positionner le droit juste sur le home de l'utilisateur, n'impactera pas les sous-dossiers et leurs droits. De plus, l'utilisateur, restant propriétaire de ce home, pourra toujours remettre le droit "w"...

[chrtophe]

Déjà positionner le droit juste sur le home de l'utilisateur, n'impactera pas les sous-dossiers et leurs droits.

J'entendais juste après la création.

l'utilisateur, restant propriétaire de ce home, pourra toujours remettre le droit "w"

Là bien vu.

[kevin066]

Bonjour,
Aucune possibilité de bloquer l’accès en w sur tous les fichiers (même avec w au niveau de other) ?

[becket]

Si, c'est possible avec SELinux

[Sve@r]

J'ai eu un cas récent (vendredi dernier), j'étais root et je voulais supprimer un dossier et l'OS m'a répondu que le dossier en question était monté en lecture seule.
Et effectivement, quand j'allais dans le dossier, en faisant un df . le dossier était bien monté sur lui-même.
Je ne sais pas comment ça a été fait (un montage loopback?) mais si c'est possible ben te suffit de monter /home/ton_user de la même façon.

[becket]

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
mount -o ro --bind / /mnt

Par exemple.

Mais si tu prends cette direction, tu dois chroot ton utilisateur

[Sve@r]

mount -o ro --bind / /mnt

Super, effectivement je viens de le faire. J'ai créé un dossier "/tmp/xxx", lui ai mis quelques trucs dedans puis j'ai tenté un mount -o ro --bind /tmp/xxx /tmp/xxx et effectivement maintenant dans /tmp/xxx je ne peux plus rien créer ni supprimer => Système de fichiers accessible en lecture seulement

Mais si tu prends cette direction, tu dois chroot ton utilisateur

Alors effectivement il y a quelques écueils à cette techno. Je viens de créer un user "toto", puis ai tenté un mount -o ro --bind /home/toto /home/toto. De là je peux faire un su - toto mais si je tente de m'y connecter via xfce ça bloque. Mais je ne pense pas qu'un chroot règle le souci. Je pense que le gestionnaire graphique a besoin de créer des trucs de travail et qu'il n'y arrive pas.
Mais l'idée me plait et pourrait plaire à kevin066

[becket]

Le seul endroit ou tu dois pouvoir ecrire, c'est dans ton répertoire personnel et dans /tmp

Pour ces répertoires la, il y plusieurs solutions en fonction des partitions ou de la techno utilisée mais pour l’empêcher de se promener dans l'arbre de base, tu dois le chroot

[Sve@r]

mais pour l’empêcher de se promener dans l'arbre de base, tu dois le chroot

Je comprends mieux la raison du chroot. Mais je n''avais pas compris que l'utilisateur n'avait pas le droit de sortir. Ca ne m'a pas semblé mentionné dans la demande du PO

[Escapetiger]

chroot (Wikipedia)

chroot (change root) est un appel système qui a également donné son nom à une commande des systèmes d'exploitation Unix permettant de changer le répertoire racine d'un processus de la machine hôte.

Histoire
L'appel système chroot est introduit lors du développement de la version 7 d'Unix en 1979. Il est ajouté à BSD par Bill Joy le 18 mars 1982, 17 mois avant la sortie de BSD 4.2 pour tester et construire son système. Un premier usage de l'appellation jail pour enfermement de shell vient de Bill Cheswick en 1991 qui avait créé un honeypot pour surveiller un cracker. Carole Fennelly décrit dans un article de janvier 1999 les premières méthodes d'évasion de jail[*].

En 2000, FreeBSD étend le concept en fournissant la commande jail.

En 2002, Nicolas Boiteux rédige le premier article décrivant la méthode pour créer un jail linux à partir de la commande chroot.

En 2003, l'utilisation plus répandue du chroot shell Linux donne naissance aux plateformes Internet de microservices applicatifs SaaS et PaaS avec une consommation facturée à l'usage des ressources du jail, prémices du cloud, de la virtualisation système des serveurs, ainsi que des technologies renommées plus tard containers (tel que Docker).

En 2005, Sun introduit les conteneurs Solaris décrits comme des « chroots sous stéroïdes ».

En 2008, LXC (qui sera utilisé par Docker plus tard) utilise la terminologie de conteneur et gagne en popularité en 2013 à la suite de son inclusion dans le noyau Linux 3.8.


Objectif
Cette commande permet d'isoler l'exécution d'un programme et d'éviter ainsi la compromission complète d'un système lors de l'exploitation d'une faille. Si un pirate utilise une faille présente sur l'application chrootée, il n'aura accès qu'à l'environnement isolé et non pas à l'ensemble du système d'exploitation. Cela permet donc de limiter les dégâts qu'il pourrait causer. Cet environnement est appelé un chroot jail en anglais, littéralement une prison.

Il permet également de faire tourner plusieurs instances d'un même ensemble de services ou démons sur la même machine hôte.

Par exemple, il est possible avec chroot d'exécuter des applications 32 bits sur un système 64 bits : il suffit pour cela d'avoir un sous-système qui intègre toutes les bibliothèques logicielles nécessaires ; chroot permet de se connecter à l'intérieur de ce sous-système et d'y exécuter les applications installées.

Outil GNU
chroot est un outil GNU faisant partie de coreutils et plus précisément des shellutils.


[*] jail (Wiktionnaire) :
«
Étymologie

De l’ancien français, jaiole.

Nom commun
Singulier Pluriel
jail
\dʒeɪl\ jails
\dʒeɪlz\

jail \dʒeɪl\

Geôle, prison.
(.../...)
»