Profils utilisateurs, administrateur (root) et droits

Demander un devis
Je souhaite télécharger le programme ou imprimer le programme
  • Imprimer

Introduction

 

Linux est un système d'exploitation multi-utilisateurs. Chaque utilisateur a plus ou moins de droits et donc plus ou moins de possibilités sur ce système. Cet article détaille la manière dont sont gérés les droits, les utilisateurs et les mots de passe sur un système UNIX ou dérivé d'UNIX (comme GNU/Linux, MacOS, Solaris, ...).

 

Dans tout ce qui suit on désigne sous le nom de fichier :

  • les dossiers (appelés aussi répertoire),
  • les fichiers réguliers (documents, exécutables, musiques, vidéos, ...),
  • ... et bien d'autres (voir en fin de tutoriel).

Pour comprendre ce tutoriel, il est recommandé d'avoir lu l'article détaillant la manière dont est organisé Linux et sur le mode texte.

    Notions de bases

    Les utilisateurs

    Introduction

     

    Un utilisateur (au sens du système Linux) peut être :

    • une personne morale :
      • par exemple l'utilisateur "mando" si vous avez créé un utilisateur mando à l'installation,
      • l'administrateur de la machine : sur un système dérivé d'UNIX, il s'appelle par défaut root,
    • un utilisateur engendré par une application pour des raisons techniques (par exemple l'utilisateur mysql est associé au serveur de base de donnée MySQL).

    Login

      Un utilisateur est identifié par un login (par exemple "mando", "root"...) et un mot de passe (qu'il doit garder secret).

       

      Convention : un login est une chaîne de caractères constitués de caractères alphanumériques en minuscules et sans caractères accentués. Par exemple l'utilisateur Jean Dupond pourrait avoir le login "jean" ou "dupond" ou n'importe quelle autre séquence de caractère respectant cette convention.

       

      Attention :

      • Linux est sensible à la casse. En d'autres termes, il fait la distinction entre les caractères minuscules et majuscules.
      • En mode texte, quand un mot de passe est demandé, rien ne s'affiche quand on le tape. Il doit être tapé en aveugle, puis être validé en appuyant sur la touche "entrée".

      Mot de passe

       

      Chaque compte utilisateur est protégé par un mot de passe. Pour avoir un mot de passe sûr, voici les règles que vous devriez suivre.

      • Il ne faut pas:
        • qu'il soit basé sur le login,
        • qu'il soit basé sur un mot du dictionnaire,
        • qu'il soit composé d'une séquence de caractères voisins sur le clavier (comme "azerty"),
        • qu'il découle d'une répétition triviale (par exemple "aaaaa").
      • Idéalement il devrait:
        • comporter des minuscules, des chiffres, des majuscules, des caractères spéciaux (par exemple #, !...)
        • être composé d'un nombre de caractères raisonnables (par exemple au moins 8 caractères).

        L'administrateur de la machine : root

        Quel est son rôle ?

         

        Sur un système Linux, l'utilisateur root désigne l'administrateur de la machine. Il est parfois aussi appelé super-utilisateur.  Contrairement aux autres utilisateurs, root a tout les droits (y compris celui de les ignorer).

         

        Prenons un exemple qui illustre le rôle de root. La configuration du système Linux est située dans /etc. Ces fichiers sont sensibles dans la mesure où ils peuvent nuire au fonctionnement d'une application et plus généralement du système Linux ou parce qu'il peuvent nuire aux autres utilisateurs. Afin qu'un utilisateur ne puisse pas en pénaliser un autre, seul root peut corriger ces fichiers. C'est la raison pour laquelle configurer un système Linux requiert souvent des droits root.

         

        Pourquoi ne doit-on pas être identifié en root en permanence ?

         

        Une session graphique ne devrait jamais être lancée en root, ainsi toutes les applications graphiques seront lancées avec des droits utilisateurs et donc restreints.

         

        De nos jours, les gestionnaires de connexion graphique (kdm, gdm...) empêchent root de se connecter en graphique. Ceci est fait pour éviter qu'une personne soit tout le temps identifiée en root. S'il le faisait, il ne serait plus protégé par le système de droits utilisateurs.

         

        Au contraire, si un utilisateur vient à lancer un programme malveillant, celui-ci aura les droits de cet utilisateur et donc ne pourra pas compromettre le système Linux. Les fichiers de cet utilisateur (et notamment son profil) restent cependant vulnérables.

         

        Résumé et bonnes pratiques

         

        • root administre le système linux et a tous les droits.
        • root ne doit pas lancer de session graphique.
        • Un utilisateur ne peut compromettre que son profil et ses documents.
        • On doit être root le moins possible, uniquement quand les circonstances l'exigent.
        • Quand des droits root sont exigés, il faut se demander si cela est légitime ou pas.

        Les sudoers

         

        Un sudoer est un néologisme formé à partir de "sudo" ("super utilisateur does" : le super utilisateur fait) et "user" (utilisateur). C'est un utilisateur moral de la machine pour qui root à débloquer des plus ou moins de droits administrateurs.

         

        Le concept de sudoer n'existe pas forcément sur un système Linux : il faut que le paquet sudo n'est pas installé.  Sous Debian par exemple, il n'est pas installé par défaut tandis qu'il l'est sous Ubuntu. Pour voir comment installer un paquet sous debian ou une distribution qui en dérive, vous pouvez vous référer à l'article sur le gestionnaire de paquets.

         

        Sous Ubuntu, afin de masquer la distinction entre root et le(s) profil(s) utilisateur(s), l'utilisateur créé à l'installation est sudoer sur l'ensemble des commandes d'administration. Cela signifie qu'il peut exécuter n'importe quelle commande qui en temps normal exigerait des droits root s'il la préfixe par la commande "sudo".

         

        Exemple : la commande "nano /etc/fstab" requiert des droits root pour que nano puisse modifier ce fichier.

         

        sudo nano /etc/fstab

         

        Lorsqu'un sudoer lance un la commande sudo, on lui demande de saisir son mot de passe (et non celui de root). Ceci est dû au fait qu'un sudoer n'est pas forcément sudoer sur toutes les commandes du système, donc il utilise son profil et non celui de root.

         

        On peut se demander pourquoi sudo demande un mot de passe qu'on a déjà saisi. Ceci empêche qu'une commande administrateur (typiquement contenue dans un script) lance une commande administrateur à l'insu du sudoer.

         

        Afin d'éviter d'avoir à taper le mot de passe sudo à chaque fois, un mécanisme est mis en place pour que seule la première commande sudo tapée dans un terminal demande un mot passe. Sa durée de vie correspond à celle du terminal et sa portée est limitée à son terminal. En d'autres termes, si ce terminal est fermé il faudra retaper le mot de passe. Si on ouvre un autre terminal, en tant que terminal indépendant, il faudra taper le mot de passe dans ce nouveau terminal.

        Les home directories

        Définitions : profil, home directory

         

        Chaque utilisateur à un dossier qui lui est propre, appelé home directory. Il stocke :

        • les documents de cet utilisateur (au même titre que le dossier "Mes Documents" sous Microsoft Windows),
        • le profil de cet utilisateur (au même titre que le dossier "AppData" sous Microsoft Windows), explicité ci-après.

        Le home directory d'un utilisateur moral est stocké en général placé comme suit dans l'aborescence Linux.

        • dans /root pour l'utilisateur root
        • dans /home pour les autres utilisateurs moraux (et locaux à la machine)par exemple /home/mando pour l'utilisateur mando, /home/toto pour l'utilisateur toto et ainsi de suite.

        L'opérateur ~ (tilde)

         

        Souvent le home directory est noté en abrégé ~root, ~mando, ~toto (respectivement pour /root, /home/mando, /home/toto). On note également ~ le home directory de l'utilisateur avec lequel on s'est identifié. Par exemple :

        • si on est identifié en root : ~ = ~root = /root
        • si on est identifié en mando : ~ = ~mando = /home/mando

         

        Profil utilisateur

        Principe

         

        Chaque utilisateur est libre de configurer à son idée son environnement de travail. Par exemple un utilisateur est libre de personnaliser la couleur des fenêtres de son environnement graphique, ses favoris Internet, son thème d'icône etc... Toutefois, si cet utilisateur n'est pas root, il ne peut pas personnaliser les fichiers de configuration contenus dans /etc et partagées partous les utilisateurs. En outre, comme cette configuration est personnalisée, elle n'a aucune raison d'impacter les autres utilisateurs.

         

        C'est la raison pour laquelle la configuration d'une application Linux est décomposée en deux parties :

        • la configuration globale : dans /etc,
        • le profil utilisateur (la configuration spécifique à un utilisateur)

        Étant donné qu'un utilisateur ne peut écrire que dans son home directory et dans /tmp, et étant donné que /tmp est purgé à chaque redémarrage, cette configuration personnalisée est forcément stockée dans le home directory de l'utilisateur.

         

        Fichiers cachés

         

        Comme le profil utilisateur est stocké dans son home directory et donc avec ses documents, il ne faut pas que les fichiers qu'il engendrent "polluent" ce qu'un utilisateur voit dans son home directory.

         

        C'est la raison pour laquelle ces fichiers sont cachés. Un fichier caché est un fichier dont le nom commence par un point ("."). Les applications Linux (par exemple la commande ls ou un explorateur de fichiers comme konqueror, dolphin ou nautilus) n'affichent pas ces fichiers sauf si on leur demande expressément.

         

        Pour affiche les fichiers cachés de son home directory on peut utiliser la commande :

         

        ls -a ~

         

        Conventions sur les profils utilisateurs

         

        Les profils sont toujours stockés à la racine du home directory sous forme de fichiers cachés. Si le profil d'une application est composé de plusieurs fichiers, ceux-ci sont souvent regroupés dans un répertoire caché qui porte le nom de l'application (par exemple ~/.kde pour le profil KDE).

         

        Si un fichier de configuration est lu au démarrage, celui-ci est souvent post-fixé "rc" (par exemple ~/.bashrc pour bash et ~/.kde/share/config/amarokrc pour l'application amarok qui fait partie de la suite KDE).

         

        Exemple : l'application vim plusieurs répertoires qui contiennent chacun des fichiers de configuration lus dans des contextes bien précis :

        • /etc/vim : la configuration de l'application vim, commune à tous les utilisateurs, uniquement modifiable par root,
        • ~mando/.vim = /home/mando/.vim : la configuration de vim spécifique à l'utilisateur mando, modifiable par mando
        • ~root/.vim = /root/.vim : la configuration de vim spécifique à l'utilisateur root (en tant qu'utilisateur, root à également un profil qui lui est propre).

         

        Quel profil suis-je en train d'utiliser ?

        En mode texte

        Conventions de notation dans un shell

         

        Les commandes "linux" que l'on lance sur un système Linux sont traitées par un shell. Ce shell peut être manipulé en mode texte ou par le biais d'un terminal graphique (comme konsole). Lorsque celui-ci est est prêt à traiter une commande, il affihe une invite de commande (appelée aussi prompt). Ce prompt rappelle notamment quel profil utilisateur est en cours d'utilisation devant le caractère "@".

         

        Exemple : voici à quoi pourrait ressembler les invites de commandes associées à mando et root sur la machine silk quand leur shell est positionné dans leur home directory (~) :

         

        (mando@silk) (~) $

        (root@silk) (~) #

         

        Le symbole qui apparaît à la fin de cette invite de commande rappelle si on utilise le profil root ou un profil utilisateur :

        • # pour root,
        • $ pour les autres utilisateurs.

        Si vous souhaitez personnaliser l'invite de commande (par exemple la mettre en couleur), vous pouvez consulter cet article.

         

        Commandes associées

         

        À tout instant on peut voir en mode texte avec quel utilisateur on est en train de travailler, grâce à la commande "whoami" même si cela est généralement rappelé dans l'invite de commande.

         

        (mando@silk) (~) $ whoami
        mando

         

        La commande "id" permet également donne des informations complémentaires, abordées ultérieurement dans cet article :

         

        (mando@silk) (~) $ id
        uid=1000(mando) gid=1000(mando) groupes=1000(mando), 20(dialout), 24(cdrom), 25(floppy), 27(sudo), 29(audio), 44(video), 46(plugdev), 113(fuse)

         

        En mode graphique

         

        Généralement ceci est indiqué explicitement à un endroit de l'interface.

        • Sous gnome : en haut à droite, à côté du bouton qui sert à quitter gnome.
        • Sous KDE : dans le menu K.

         

        k_kickoff

         

        Comment changer de profil ?

         

        L'utilisateur avec lequel on est identifié aura la possibilité d'accéder à plus ou moins de fichiers et de lancer plus ou moins de commandes. Souvent on ouvre une session graphique avec un profil utilisateur. Puis lorsqu'on doit installer un logiciel (et donc administrer la machine) on a besoin de droits root. Cette section présente comment changer de profil.

         

        En mode texte

         

        Avec la commande su

         

        Sous la plupart des distributions Linux, pour devenir l'utilisateur toto on tape :

         

        su - toto

         

        Notez qu'on pourrait taper simplement "su toto", mais ceci ne recharge pas le profil de toto. Ainsi il est préférable de toujours mettre le symbole "-".

         

        Si l'utilisateur est sous-entendu derrière la commande "su", il s'agit implicitement de root. Ainsi ces deux commandes sont équivalentes :

         

        su - root
        su -

         

        Avec la commande sudo

         

        Sous Ubuntu, le profil root n'est pas activé par défaut. Pour lancer un shell root il faut lancer la commande :

         

        sudo -s

         

        On peut activer le profil root grâce à la commande :

         

        sudo passwd root

         

        Pour installer sudo sous Debian, lancez en root :

         

        aptitude update

        aptitude safe-upgrade

        aptitude install sudo

         

        Supposons que vous souhaitiez rendre l'utilisateur mando sudoer (apte à lancer n'importe quelle commande sudo), il suffit de l'ajouter au groupe sudo (voir /etc/sudoers pour plus d'explications). Ceci se fait en tapant la commande :

         

        addgroup mando sudo

         

        Afin de faire partie du groupe sudo, l'utilisateur mando n'a plus qu'à quitter sa ou ses sessions et en ouvrir une nouvelle.

         

        Quitter la session root

         

        Invoquer la commande su, ssh, chroot etc... consiste à empiler un shell (un interpréteur de commande) par dessus un ancien shell. Sur le même principe qu'une pile d'assiette, le shell actif est celui qui est sur le dessus de la pile.

         

        Pour dépiler un shell, il faut lancer la commande "logout" ou "exit" en fonction de la dernière commande qui a servi à empiler un shell ou directement le raccourci clavier "ctrl d".

         

        konsole_su

        En mode graphique

         

        root ne doit jamais lancer de session graphique. Toutefois il peut arriver que l'on ait besoin de lancer une application graphique avec des droits root. Par exemple, on peut souhaiter lancer l'application systemsettings (le panneau de configuration de KDE4) avec des droits root pour configurer kdm (le gestionnaire de connexion graphique proposé par KDE).

         

        Avec kdesudo ou gksudo

         

        Pour lancer une application graphique avec de droits root on utilise généralement :

        • kdesudo (sous KDE),
        • gksudo (sous gnome).

        Ces deux commandes lancent une fenêtre dans laquelle on peut saisir un mot de passe pour à terme lancer une application avec des droits root. Pour que cela fonctionne, l'utilisateur qui invoque la commande kdesudo ou gksudo doit être un sudoer. Ce point de configuration est détaillé dans les notions avancées.

         

        kdesudo

         

         

        Pour installer kdesudo, et pour faire en sorte que l'utilisateur mando puisse lancer des commandes administrateur via sudo, lancez en root :

         

        aptitude update

        aptitude safe-upgarde

        aptitude install kdesudo

         

        On ajoute mando au groupe sudo pour qu'il puisse utiliser la commande sudo sur n'importe quelle commande administrateur. Cela revient à dire que mando pourra faire tout ce que root peut faire via sudo (sous réserve de taper son mot de passe).

         

        addgroup mando sudo

         

        Puis relancez votre session graphique.

         

        Exemples d'utilisation :

         

        gksudo gedit /etc/fstab

        kdesudo kwrite /etc/fstab

        kdesudo systemsettings

         

        Remarques :

        • Si kdesudo ou gksudo ne semblent pas marcher (par exemple ils ne lancent ni gedit ni kwrite après avoir saisi le mot de passe), c'est probablement que votre utilisateur n'est pas un sudoer sur la commande que vous tentez de lancer
        • Même si cela fonctionne, on ne devrait jamais lancer une application graphique au travers de la commande "sudo". En effet, gksudo et kdesudo prennent le soin de travailler avec un fichier " ~/.Xauthority" temporaire et ne risquent pas de corrompre la session graphique courante.

        Grâce aux commandes xhost et su

         

        A priori seul l'utilisateur qui a lancé la session graphique peut y ouvrir une fenêtre. Un utilisateur peut décider d'autoriser quelqu'un d'autre à dessiner dans sa session grâce à la commande xhost. La commande xhost suivante va permettre à une session root locale à la machine d'ouvrir une fenêtre dans la session graphique courante.

         

        xhost +local:root@

        su -

        kwrite /etc/fstab

         

        Pour remettre les permissions xhost dans leur état initial :

         

        xhost -local:root@

        Les groupes

        Définition

         

        Les groupes permettent de désigner sous un nom une catégorie d'utiliisateurs afin de leur associer une politique d'accès commune à un fichier. Par exemple, on peut imaginer que seul root et les membres du groupe "audio" puissent accéder à /dev/dsp, le fichier qui permet d'envoyer un son vers la carte son.

         

        Propriétés d'un groupe :

        • Un groupe est défini à partir d'une liste d'utilisateur éventuellement vide.
        • Un groupe ne peut pas être défini à partir d'autres groupes.
        • Si un fichier doit avoir une politique commune pour plusieurs groupes, il est possible de s'en sortir avec des droits ACL (voir en fin d'article).
        • Un utilisateur peut appartenir à plusieurs groupes.

        Un utilisateur peut voir à tout instant à quels groupes il appartient en lançant la commande groups.


        Exemple :

         

        (mando@silk) (~) $ groups
        mando dialout cdrom floppy sudo audio video plugdev fuse

        Ici, mando est membre des groupes mando, dialout, cdrom, floppy, sudo, audio, video, plugdev et fuse.

         

        Résumé et bonnes pratiques

        • Un groupe rassemble un ensemble d'utilisateurs en vue d'appliquer une politique de droits commune à ces utilisateurs.
        • Pour augmenter les droits de mando (par exemple lui permettre d'accéder à certains périphérique), root doit ajouter mando dans les bons groupes.
        • En aucun cas root ne doit relâcher les permissions associées à un périphérique, à une commande et plus généralement à un fichier.

        Les droits POSIX

        Introduction

         

        À chaque fichier (dossiers, les fichiers réguliers...) on attribue des droits. Les droits servent définir une politique d'accès et d'utilisation sur un fichier. Par exemple, on peut autoriser ou non un utilisateur de lire un document, de le modifier, de lancer un programme etc... Cependant on ne pourra jamais empêcher root d'accéder à un fichier.

         

        Sous Linux, il existe différentes couches de droits qui interviennent dans différents contextes. Celles-ci sont présentées dans les notions avancées. Dans cet article, nous allons nous focaliser essentiellement sur la couche de droits POSIX. Celle-ci s'inspire des droits qui existent sur un système UNIX.

         

        Ces droits sont utilisés pour sécuriser le système. Par exemple, seul root peut intervenir sur les fichiers qui servent à faire fonctionner  le système Linux (ce qui inclue les commandes Linux, les fichiers qui de configuration du système etc...). Les droits associés à ces fichiers de devraient jamais être modifiés. Les relâcher pourrait permettre à un utilisateur potentiellement malveillant  de corrompre des fichiers sensibles. Cela reviendrait donc à ouvrir une faille de sécurité.

         

        Ainsi, l'administration des droits POSIX sert principalement si un utilisateur veut ou non restreindre l'accès à ses propres documents.

         

        A priori, les droits Linux sont configurés de sorte à ce qu'un utilisateur ne puisse créer des fichiers que dans son home directory et dans /tmp (le répertoire contenant les fichiers temporaires, purgé à chaque redémarrage).

         

        Avant de présenter plus précisément les droits, il est recommandé de lire l'article détaillant les différents types de fichiers qui existent sous Linux.

        Principe

         

        À chaque fichier est attribué à un utilisateur propriétaire et un groupe propriétaire (un groupe étant un ensemble d'utilisateurs). Les droits sont attribués à trois catégories d'utilisateurs :

        • les droits associés à l'utilisateur propriétaire (u),
        • les droits associés au groupe propriétaire (g),
        • les droits associés aux autres (o).

        À chacune de ces trois catégories, on associe trois droits "rwx" (pour un total de neuf droits) :

        • Les droits en lecture (r) :
          • pour un fichier régulier : peut-il être ouvert et lu ?
          • pour un socket : peut-on récupérer les informations émises par l'application distante ?
          • pour un device : peut-on récupérer le signal émis par le périphérique ? Par exemple pour une souris, peut-on récupérer le signal associé aux mouvements et aux clics de la souris ?
        • Les droits en écriture (w) :
          • pour un fichier régulier : peut-il être modifié, renommé, supprimé ?
          • pour un répertoire : peut-on renommer ou supprimer son contenu ?
          • pour un device : est-ce que l'utilisateur peut émettre un flux d'information vers le périphérique associé ? Par exemple pour une carte son, peut-on jouer du son avec cette carte son ?
          •  pour un socket : est-ce que l'utilsateur peut émettre du trafic réseau vers l'application distante ?
        • Les droits en exécution (x) :
          • pour un fichier régulier : est-ce que le fichier peut être exécuté (typiquement, il faut avoir les droits en exécution pour pouvoir lancer un programme) ?
          • pour un répertoire : peut-on entrer dedans ?

        Il existe également quelques droits supplémentaires (bits set-UID, set-GID et sticky-bit) qui sont utilisés dans des contextes très particuliers et qui sont détaillés dans les notions avancées.

         

        Comme sous Linux, tout est représenté par un fichier (répertoire, socket, fichiers réguliers, périphériques) et que la notion de droits s'applique à n'importe quel fichier, les droits peuvent impacter si un utilisateur va pouvoir par exemple travailler ou non avec un périphérique. Par exemple si un utilisateur n'a pas possibilité

          Un premier exemple

           

          La commande suivante affiche les droits associés au fichier /etc/shadow :

           

          (mando@silk) (~) $ ls -l /etc/shadow
          -rw-r----- 1 root shadow 881 29 déc.  15:57 /etc/shadow

           

          Parmi les informations qu'on relève, on observe :

          • Le premier caractère (ici "-") décrit la nature du fichier (ici un fichier régulier). Pour plus de détails sur les différents caractères qui peuvent apparaître ici, consultez cet article.
          • Une série de droits, détaillés juste après,
          • La dernière date à laquelle on a accédé à ce fichier,
          • L'utilisateur propriétaire est "root"
          • Le groupe propriétaire est "shadow".

          Pour les droits : rw-r-----

          • Le premier triplet "rw- " donne des droits en lecture (r), écriture (w), mais pas exécution (- au lieu de x) à l'utilisateur propriétaire, ici root.
          • Le second triplet "r--" donne uniquement des droits en lecture au groupe propriétaire, ici shadow. Le groupe propriétaire n'a ni droit en écriture (- au lieu de w) ni en exécution (- au lieu de x).
          • Le troisième triplet "---" ne donne aucun droits aux autres utilisateurs.

          Ainsi, dans cet exemple :

          • seul root et les membres du groupe shadow peuvent lire ce fichier,
          • seul root peut modifier ce fichier,
          • personne ne peut exécuter ce fichier.

          Chaîne de droits

           

          Considérons le programme /home/mando/plop.sh que l'on souhaite exécuter. Pour pouvoir l'exécuter il faut pouvoir entrer dans le répertoire /home, puis dans le sous répertoire /home/mando et enfin pouvoir exécuter le programme plop.sh. Si un seul de ces droits manque, il sera impossible de lancer ce programme.

           

          Le principe est le même quel que soit le fichier et la manière dont on veut y accéder (en lecture, en écriture ou en exécution). Il faut pouvoir traverser toute la chaîne de répertoires qui contient le fichier auquel on veut accéder et avoir les droits associés

           

          Résumé et bonnes pratiques

           

          • root a tous les droits (sur sa machine) au sens de la couche de droit POSIX. Si en root vous recevez un message de permission refusée (permission denied) consultez la rubrique associée dans les notions avancées.
          • Il ne faut jamais modifier les droits appliqués aux fichiers du système.
          • Un utilisateur peut restreindre ou relâcher les droits appliqués à ses fichiers personnels, mais hormis root, il ne peut pas en modifier le propriétaire ou le groupe propriétaire.
          • Sous Linux, on ne relâche jamais les droits associés

          Notions avancées

          Utilisateurs locaux à la machine

          Définitions

           

          Dans ce qui suit, on parle des utilisateurs au sens  du système Linux, c'est-à-dire les utilisateurs capables de lancer un processus sur la machine (on ne parle donc pas des utilisateurs spécifiques à une application comme un serveur de base de donnée ou un client de messagerie instantanée).

           

          On appelle utilisateur local à la machine un utilisateur dont l'intégralité des informations (mot de passe, fichiers personnels...) est présent sur la machine en question, par opposition à un utilisateur itinérant. En terme de configuration :

          • Ses caractéristiques sont stockés dans /etc/passwd.
          • Son mot de passe devrait toujours être stocké dans /etc/shadow. S'il figure dans /etc/passwd, le système est mal administré (voir la suite de l'article pour remédier à ce problème).

            Cas particulier : l'utilisateur root

             

            Contrairement aux autres utilisateurs de la machine, son home directory n'est pas stocké dans /home (ainsi /home/root n'est pas sensé exister), mais dans /root. Ceci est dû a des raisons pratiques. Bien souvent, on partitionne Linux de sorte à stocker /home et / sur deux partitions différentes (voir l'article sur le partitionnement). Ceci présente plusieurs avantages.

            • Si la partition /home est corrompue, root à toujours possibilité d'accéder à ses documents. En outre il a toujours accès à son profil.
            • De plus, étant donné qu'il est sur une partition différente, les autres utilisateurs ne peuvent pas saturer la partition sur laquelle root stocke ses documents, même si par défaut, 5% de l'espace d'une partition est toujours réservée à root (voir étape de partitionnement à l'installation).

            Attention : sous Linux le mot "root" peut avoir plusieurs significations :

            • l'utilisateur root (référencé dans /etc/passwd),
            • le groupe root (référencé dans /etc/group),
            • le root directory (le répertoire racine, en d'autres termes /),
            • le home directory de root (le répertoire /root).

            /etc/passwd

             

            Ce fichier rassemble pour chaque utilisateur un ensemble d'information à raison d'une ligne par utilisateur et d'une colonne par type d'information. Chaque colonne est délimitée par le caractère ":".

             

            Exemple : le système Linux utilisant le fichier /etc/passwd ci-dessous comporte  un utilisateur root, daemon, bin etc... Certains de ces utilisateurs sont associés à une personne réelle qui peut s'authentifier et lancer des commandes (mando et root ici), tandis que d'autres sont associés à des concepts ou des applications (par exemple un serveur mysql est lancé par le système grâce à ul'tilisateur mysql).

             

            root:x:0:0:root:/root:/bin/bash
            daemon:x:1:1:daemon:/usr/sbin:/bin/sh
            bin:x:2:2:bin:/bin:/bin/sh
            sys:x:3:3:sys:/dev:/bin/sh
            sync:x:4:65534:sync:/bin:/bin/sync
            games:x:5:60:games:/usr/games:/bin/sh
            man:x:6:12:man:/var/cache/man:/bin/sh
            lp:x:7:7:lp:/var/spool/lpd:/bin/sh
            mail:x:8:8:mail:/var/mail:/bin/sh
            news:x:9:9:news:/var/spool/news:/bin/sh
            uucp:x:10:10:uucp:/var/spool/uucp:/bin/sh
            proxy:x:13:13:proxy:/bin:/bin/sh
            www-data:x:33:33:www-data:/var/www:/bin/sh
            backup:x:34:34:backup:/var/backups:/bin/sh
            list:x:38:38:Mailing List Manager:/var/list:/bin/sh
            irc:x:39:39:ircd:/var/run/ircd:/bin/sh
            gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/bin/sh
            nobody:x:65534:65534:nobody:/nonexistent:/bin/sh
            libuuid:x:100:101::/var/lib/libuuid:/bin/sh
            mando:x:1000:1000:mando,,,:/home/mando:/bin/bash
            messagebus:x:101:104::/var/run/dbus:/bin/false
            haldaemon:x:102:107:Hardware abstraction layer,,,:/var/run/hald:/bin/false
            saned:x:103:111::/home/saned:/bin/false
            mysql:x:104:112:MySQL Server,,,:/var/lib/mysql:/bin/false
            usbmux:x:105:46:usbmux daemon,,,:/home/usbmux:/bin/false
            sshd:x:106:65534::/var/run/sshd:/usr/sbin/nologin
            proftpd:x:107:65534::/var/run/proftpd:/bin/false
            ftp:x:108:65534::/home/ftp:/bin/false
            munin:x:109:115::/var/lib/munin:/bin/false
            cl-builder:x:110:116::/usr/share/common-lisp/:/bin/false
            

             

            Voici la signification de chaque colonne.

            1. Le login : il est utilisé pour s'identifier, il apparaît dans la table des processus, pour indiquer quel utilisateur a lancé quel processus.
            2. Le mot de passe : cette colonne indique si le profil est protégé par un mot de passe déporté dans /etc/shadow (x), pas protégé par un mot de passe (aucun caractère entre les deux délimiteurs ":"). Si le système est mal administré, le mot de passe chiffré peut apparaître dans cette colonne.
            3. L'UID (User IDentifier) : le numéro associé à l'utilisateur, utilisé pour gérer notamment les droits,
            4. le GID (Group IDentifier) par défaut : le numéro associé au groupe auquel doit appartenir les fichiers créés par cet utilisateur. Pour plus de détails, regardez la section portant sur /etc/group.
            5. Les informations associées à l'utilisateur : cette colonne permet à l'administrateur de stocker des informations plus parlante. Typiquement on peut y indiquer le nom réel associé à un login (par exemple Jean Dupond), son numéro de téléphone, le bureau dans lequel il travaille etc...
            6. Le shell par défaut : le shell permet à un utilisateur de lancer des commandes Linux. Un shell a plus ou moins de fonctionnalités. Cette colonne permet d'empêcher qu'un utilisateur ne lance un shell (typiquement les utilisateurs créés pour des besoins techniques comme l'utilisateur mysql).

             

            Pourquoi le mot de passe n'est pas (ne devrait pas) être stocké dans /etc/passwd ?

             

            Dans des temps reculés, ce fichier stockait les mots de passe associés à chaque utilisateur, d'où son nom. Toutefois, pour des raisons techniques (résolution de l'opérateur ~, résolution des UID lorsqu'on affiche les droits associés à un fichier ou les processus actifsetc...), ce fichier doit être lisible de tous. Comme le mot de passe est une information sensible, il était stocké sous forme chiffrée dans ce fichier. Malheureusement, constitue une faille de sécurité : des utilisateurs mal attentionnés peuvent tenter de retrouver des mots de passe à partir de cette information.

             

            Quand on tape un mot de passe au moment de s'authentifier, on compare si cette saisie une fois chiffrée correspond au mot de passe chiffré stocké dans ce fichier. Des outils comme john permettent de retrouver un mot de passe qui a partir d'un mot de passe chiffré tente de trouver un mot de passe qui produira le même mot de passe chiffré. Selon le mot de passe utilisé (voir dans la première partie comment définir un mot de passe sûr), le mot de passe sera plus long à retrouver.

             

            Quoi qu'il en soit, exposer un mot de passe même chiffré dans ce fichier représente une faille de sécurité, car un utilisateur utilisant ce genre de logiciel sera en mesure d'accéder au mot de passe d'autres utilisateurs ayant plus de droits (typiquement root) et par suite, compromettre la sécurité du système Linux. C'est la raison pour laquelle le mot de passe (chiffré) n'est jamais sensé figurer dans ce fichier et devrait toujours être déporté dans /etc/shadow. Si c'est le cas, la deuxième colonne du fichier /etc/passwd comporte le caractère "x".

            /etc/shadow

             

            Le fichier /etc/shadow stoke le mot de passe de chaque utilisateur local à la machine, root compris. Contrairement à /etc/passwd, ce fichier n'est lisible que de root et des membres du groupes shadow (a priori, juste root). Sa structure rappelle fortement celle de /etc/passwd. On peut remarquer dans ce fichier que le mot de passe entre deux utilisateurs correspond, ce n'est pas forcément le cas du mot de passe chiffré dans ce fichier.

             

            Quand un utilisateur modifie son mot de passe, son mot de passe peut être répercuté :

            • dans /etc/shadow si le caractère "x" est positionné sur la ligne associé à son login et dans la deuxième colonne, il y a autre chose que le caractère "x",
            • dans /etc/passwd sinon (ce qui est mauvais).

            Ainsi, avant de corriger un mot de passe, on devrait toujours veiller à ce que ce caractère x soit positionné au préalable.

             

            Bit set-UID (drapeau SUID)

            Qu'est-ce que c'est ? À quoi ça sert ?

             

            Indépendemment du fichier dans lequel est stocké le mot de passe, on peut se demander comment un utilisateur local peut modifier à terme un fichier sur lequel il n'a pas de droits en écriture. Ceci entre en contradiction avec la notion de droits POSIX. Les commandes permettant d'intervenir tantôt sur /etc/passwd ou /etc/shadow sont nombreuses :

            • passwd : change le mot de passe (donc corrige la deuxième colonne de /etc/passwd ou /etc/shadow),
            • chsh : change le shell par défaut (donc la dernière colonne de /etc/passwd),
            • chfn : changer les informations liées à un utilisateur (donc la 5e colonne de /etc/passwd),
            • ...

            Chacune de ces commandes est en réalité munie d'un bit Set-UID, représenté par un "s" au lieu du "x" habituel au niveau des droits en exécution associés à l'utilisateur propriétaire :

             

            Exemple : Les commandes suivantes reviennent à faire "ls -l /usr/bin/passwd", "ls -l /usr/bin/chsh" , "ls -l /usr/bin/chfn"

             

            (mando@silk) (~) $ ls -l $(which passwd)
            -rwsr-xr-x 1 root root 34740 26 sept. 00:05 /usr/bin/passwd
            (mando@silk) (~) $ ls -l $(which chsh)
            -rwsr-xr-x 1 root root 27956 26 sept. 00:05 /usr/bin/chsh
            (mando@silk) (~) $ ls -l $(which chfn)
            -rwsr-xr-x 1 root root 36372 26 sept. 00:05 /usr/bin/chfn

            Lorsqu'un utilisateur mando lance la commande (et donc le processus) passwd, chsh ou chfn, il ne le lance pas avec ses droits, mais avec ceux du propriétaire du fichier (ici root). Or root peut accéder à ces fichiers d'administration. Ainsi, grâce au mécanisme de bit Set-UID, un utilisateur peut acquérir ponctuellement les droits d'un autre utilisateur.

             

            Les fichiers munis d'un bit Set-UID sont affichés sur fond rouge quand la commande ls est utilisée.

             

            Est-ce qu'un bit Set-UID peut devenir dangereux ? Qu'est ce qu'un backdoor ?

             

            Un administrateur doit être particulièrement vigilant à ce que fait un bit Set-UID. En particulier, n'importe qui peut écrire un programme muni d'un bit Set-UID. Ceci n'est pas gênant où un utilisateur A peut décider à ces risques et périls d'autoriser un utilisateur B à lancer un programme comme si c'était A qui le lançait.

             

            Le problème survient le jour ou le programme est peut devenir malveillant et où le propriétaire A... est root. Si par exemple le  programme consiste à lancer un shell, que celui-ci appartient est muni d'un bit Set-UID et que ce programme appartient à root, n'importe quel utilisateur est capable de lancer un terminal root sans avoir à connaître son mot de passe ! C'est le principe d'un backdoor.

             

            Exemple :

             

            Si le paquet gcc un utilisateur mando peut écrire le fichier plop.c suivant qui consiste simplement à lancer un shell :

             

            #include <unistd.h>
            
            int main()
            {
                    setuid(0); // passe l'UID à 0 (utilisateur root)
                    setgid(0); // passe le GID à 0 (groupe root)
                    execl("/bin/sh","sh",0); // lance le shell "sh"
                    return 0;
            }
            

             

            À présent, compilons ce programme grâce à gcc et attribuons-lui un bit Set-UID.

             

            (mando@silk) (~) $ gcc -W -Wall plop.c -o plop

            (mando@silk) (~) $ chmod u+s plop

            (mando@silk) (~) $ ls -l plop

            -rwsr-xr-x 1 mando mando 4743 12 janv. 17:47 plop

             

            Si un utilisateur toto lance le programme "/home/mando/plop" alors il lancera un shell comme si c'était mando qui l'avait lancé, car le bit Set-UID est positionné. Notez que ce shell (dans lequel on exécute la commande whoami ci-dessous) n'a demandé à aucun moment le mot de passe de mando :

             

            toto@silk:~$ /home/mando/plop

            $ whoami

            mando

            Si le fichier /home/mando/plop appartenait à root, alors ce shell aurait été lancé en tant que root. Heureusement, ceci n'est pas possible si root est vigilant. En effet, la commande chown, qui permet d'attribuer un fichier à un propriétaire (ici /home/mando/plop) requiert des droits root.

             

            (mando@silk) (~) $ chown root plop
            chown: changement de propriétaire pour « plop »: Opération non permise

            Ainsi un utilisateur malveillant de pourra pas aller jusqu'au bout du processus. Toutefois, si un pirate informatique s'est introduit sur le système et a pu devenir au moins une fois root sur la machine, il est très probable qu'il en ait profité pour créer un tel backdoor. Notez que changer le propriétaire d'un fichier désactive le bit Set-UID.

             

            (mando@silk) (~) $ su -

            Mot de passe :

            (root@silk) (~) # chown root /home/mando/plop

            (root@silk) (~) # chmod u+s /home/mando/plop

            (root@silk) (~) # logout

             

            Désormais, mando peut lancer un shell root avec tous les problèmes de sécurité que cela induit !

             

            (mando@silk) (~) $ /home/mando/plop

            # whoami

            root

             

            Comment s'en prémunir ?

             

            Au moment de monter un système de fichiers, il faut se demander si celui-ci peut légitimement contenir des fichiers munis de bit set-UID. C'est par exemple le cas de / (qui contient par exemple /usr/bin/passwd si on a pas fait de partition dédiée pour /usr). Par contre un média USB ou CD-ROM n'a a priori pas de raison d'en contenir. Ainsi un média amovible devrait toujours être monté avec l'option nosuid, surtout si le système de fichiers est attribué à l'utilisateur root.

             

            Comme les bits set-UID sont désactivés quand on utilise la commande chown, si on réattribue une arborescence à root et sicelle-ci comportait des programmes malveillants munis du bit set-UID, on n'introduira pas par étourderie de backdoor.

            Les utilisateurs itinérants

             

            Un utilisateur est dit itinérant à partir du moment une partie de ses informations provient d'une autre machine. Ce peut-être :

            • son mot de passe et les informations qui lui sont associées (celles qu'on trouverait dans /etc/passwd ou /etc/shadow),
            • son home directory.

            Concrètement, les informations relatives à un utilisateur peuvent être importées grâce à un serveur un serveur comme NIS ou grâce à active directory. Dans ce cas les informations associées à cet utilisateur sont partiellement remplies dans /etc/passwd et /etc/shadow. Si le serveur de mot de passe devient injoignable (par exemple suite à une panne réseau ou si le serveur en question a planté), les utilisateurs itinérants ne pourront plus s'identifier et ouvrir de session.

             

            Par ailleurs, ses fichiers peuvent être importés depuis un partage réseau samba (NAS) ou NFS. Que l'on utilise samba ou NFS, la machine distante est appelée serveur de fichiers. Si le serveur de fichiers devient injoignable, alors le home directory des utilisateurs distants n'existera pas. Concrètement, quand un tel utilisateur s'identifiera, le shell qu'il lancera ne parviendra pas à se positionner dans son home directory. Il ne pourra donc guère travailler que dans /tmp ce qui est assez limité ! De plus, comme son home directory est devenu inaccessible, il n'aura pas accès à son profil utilisateur. Ainsi, de nombreuses applications (et en particulier l'environnement graphique) ne pourront pas s'initialiser correctement. Concrètement cela se traduira par des messages d'erreur juste après s'être authentifié.

            Les sudoers

             

            Les sudoers sont des utilisateurs pour lesquels root a donné des droits administrateurs. Sous ubuntu on attribue aux membre du groupe "sudo" les mêmes droits que root (c'est-à-dire qu'ils peuvent lancer n'importe quelle commande requièrant des droits root). Dans le fichier /etc/sudoers, cela correspond à la ligne suivante :

             

            %sudo ALL=(ALL:ALL) ALL
            

             

            On peut associer à utilisateur des règles plus fines ne lui permettant de lancer que certaines commandes requièrant des droits root.

            /etc/sudoers

             Voici le fichier /etc/sudoers par défaut, qui permettent aux membres du groupe sudo de lancer n'importe quelle commande requiérant des droits root par le biais de la commande sudo :

             

            #
            # This file MUST be edited with the 'visudo' command as root.
            #
            # Please consider adding local content in /etc/sudoers.d/ instead of
            # directly modifying this file.
            #
            # See the man page for details on how to write a sudoers file.
            #
            Defaults        env_reset
            
            # Host alias specification
            
            # User alias specification
            
            # Cmnd alias specification
            
            # User privilege specification
            root    ALL=(ALL:ALL) ALL
            
            # Allow members of group sudo to execute any command
            %sudo   ALL=(ALL:ALL) ALL
            
            #includedir /etc/sudoers.d
            

            Corriger la politique des sudoers avec visudo

             

            Pour des raisons techniques diverses (qui a des droits root au moment où le fichier est corrigé, qui les aquière et qui les perd) toute modification apportée à ce fichier doit se faire par le biais de la commande visudo :

             

            visudo -s

             

            Notez que l'éditeur texte lancé n'est pas nécessairement vi mais peut être basé sur nano.

            Principales commandes d'administration

             

            CommandeRôleDroits root ?
            whoami Affiche en qui on est identifié (loggué) Non
            id Affiche les informations liées à l'utilisateur courant Non

            su -

            su - toto

            Devenir root (empile un shell root)

            Devenir toto (empile un shell toto)

            Non (*)

            Non (*)

            logout

            exit

            En fonction du contexte, dépile le shell du dessus.

            Raccourci : ctrl d

            Non
            adduser toto Créé un utilisateur toto (évitez d'utiliser useradd, moins complet) Oui
            deluser toto Supprime l'utilisateur toto (et son groupe primaire, voir section sur les groupes) Oui
            pwck Valide /etc/passwd Oui

            passwd

            passwd toto

            Change le mot de passe de l'utilisateur courant

            Change le mot de passe de toto

            Non

            Oui (sauf pour toto)

            visudo -s Administre les sudoers (voir section dédiée) Oui
            ypcat passwd Équivalent à cat /etc/passwd, mais pour les utilisateurs itinérants Non

             

            (*) Pour les systèmes basés sur BSD ou partiellement sur BSD (comme la distribution Linux Gentoo), la commande su ne fonctionne avec succès que si l'utilisateur qui invoque cette commande appartient au groupe "wheel". Pour voir comment ajouter un utilisateur à un groupe, consultez la section sur les groupes.

             

            Les groupes

            Groupe local

             

            On appelle groupe local à une machine un groupe dont l'ensemble des informations est configuré sur cette machine (par opposition à un groupe itinérant qui peut être configuré par le biais d'un serveur NIS).

             

            /etc/group

             

            Voici à quoi ressemble le fichier /etc/group :

             

            root:x:0:
            daemon:x:1:
            bin:x:2:
            sys:x:3:
            adm:x:4:
            tty:x:5:
            disk:x:6:
            lp:x:7:
            mail:x:8:
            news:x:9:
            uucp:x:10:
            man:x:12:
            proxy:x:13:
            kmem:x:15:
            dialout:x:20:mando
            fax:x:21:
            voice:x:22:
            cdrom:x:24:mando
            floppy:x:25:mando
            tape:x:26:
            sudo:x:27:mando
            audio:x:29:mando
            dip:x:30:
            www-data:x:33:
            backup:x:34:
            operator:x:37:
            list:x:38:
            irc:x:39:
            src:x:40:
            gnats:x:41:
            shadow:x:42:
            utmp:x:43:
            video:x:44:mando
            sasl:x:45:
            plugdev:x:46:mando
            staff:x:50:
            games:x:60:
            users:x:100:
            nogroup:x:65534:
            libuuid:x:101:
            crontab:x:102:
            ssh:x:103:
            mando:x:1000:
            messagebus:x:104:
            lpadmin:x:105:
            utempter:x:106:
            haldaemon:x:107:
            powerdev:x:108:
            netdev:x:109:
            scanner:x:110:saned
            saned:x:111:
            mysql:x:112:
            fuse:x:113:mando
            ssl-cert:x:114:
            munin:x:115:
            cl-builder:x:116:
            

             

            De la même façon que le fichier /etc/passwd, ce fichier peut être vu comme une sorte de tableau dans lequel chaque colonne est délimité par le caractère ":" :

            1. Nom du groupe.
            2. Indique si le groupe est protégé par un mot de passe déporté dans /etc/gshadow (fonctionne sur le même principe que /etc/passwd et /etc/shadow). Ce mot de passe est utilisé par les personnes qui peuvent administrer ce groupe.
            3. GID (Group Identifier) : identifiant numérique associé au groupe.
            4. Liste des utilisateurs membres du groupe.

            Notez que dans cet exemple, le groupe 1000 (mando) semble ne comporter aucun membre. En réalité, l'utilisateur mando appartient implicitement au groupe mando.

            Administration d'un groupe local

             

            En temps normal, ajouter un membre à un groupe consiste à utiliser la commande addgroup. Au final cette commande consiste simplement à ajouter le login de ce membre dans /etc/group à la ligne associée au groupe.

             

            Exemple : pour ajouter mando au groupe sudo, on lance simplement en root la commande :

             

            addgroup mando sudo

             

            En réalité, les groupes ne sont pas forcément administrés par root. Un groupe est caractérisé par deux listes, stockées dans /etc/gshadow :

            • une liste de membres (-M) que nous avons vu dans /etc/group,
            • une liste d'administrateurs (-A).

            Les administrateurs du groupe doivent alors saisir le mot de passe du groupe pour l'administrer. Ce mot de passe est donc connu par tous les administrateurs du groupe avec les risques que cela implique (plusieurs utilisateurs partagent un même mot de passe).

             

            Groupe primaire et groupes secondaires

             

            Un utilisateur appartient toujours au moins à un groupe, appelé groupe primaire.

            • On appelle groupe primaire le groupe associé par défaut à un utilisateur (voir /etc/passwd).
            • Les autres groupes auquel il appartient sont appelés groupes secondaires.

            Si on examine le fichier /etc/passwd donné en exemple, l'utilisateur mando est associé au groupe dont le GID est 1000. Il s'agit de son groupe primaire. Si on examine /etc/group, on s'aperçoit que le groupe 1000 s'appelle mando. Ainsi le groupe primaire de l'utilisateur mando est le groupe mando. Les autres groupes auquel il appartient (dialout, cdrom, floppy...) constituent ses groupes secondaires.

             

            Bit Set-GID (drapeau SGID)

             

            Le bit Set-GID fonctionne exactement sur le même principe que le bit Set-UID à ceci près qu'il porte sur le groupe propriétaire et non sur l'utilisateur propriétaire (avec les avantages et risques que cela implique).

             

            Commandes d'administration

             

            CommandeRôleDroits root ?
            groups Affiche les groupes auxquel appartient l'utilisateur courant Non
            id Affiche les informations liées à l'utilisateur courant Non
            groupadd users Créé le groupe users Oui
            groudel users Supprime le groupe users Oui
            addgroup toto users

            Ajoute toto au group users

            Attention : toto devra sans doute se relogguer pour que cet ajout soit effectif !

            Oui
            delgroup users Retire l'utilisateur toto du groupe users Oui
            grpck Valide /etc/group Oui
            gpasswd users Change le mot de passe du groupe users Oui
            ypcat group Équivalent à cat /etc/group, mais pour les groupes itinérants Non

             

            Les droits UNIX / POSIX

            Comment sont mémorisés les droits ?

             

            Pour comprendre cette section, il est recommandé d'avoir lu au préalable l'article sur le partitionnement et sur comment monter un système de fichiers.

             

            Les droits ne sont pas stockés à l'intérieur des fichiers lui-même :

            • d'une part car seuls fichiers réguliers peuvent stocker de l'information,
            • en admettant que le fichier considéré puisse stocker de la donnée, on ne veut pas en modifier le contenu !

            Les droits sont stockés le système de fichiers (filesystem), noté en abrégé "fs". Le système de fichiers est notamment responsable de l'organisation d'un média. Un média peut être une partition de disque dur, une clé USB, un partage réseau etc...

             

            Cette organisation comprend la manière dont est structurée l'arborescence, mais également les informations associées à chaque nœud de l'arborescence appelé inode. Parmi ces informations peuvent figurer :

            • le nom du fichier,
            • la taille du fichier,
            • les droits associés à ce fichier
              • l'UID du propriétaire,
              • le GID du groupe propriétaire,
              • les droits d'accès
            • les dates d'accès,
            • la nature du fichier (fichier régulier, répertoire, socket, device...),
            • ...

            Ainsi, les commandes permettant de corriger les droits associés à un fichier ne font à terme que corriger les inodes correspondants, sous réserve bien entendu que le système de fichiers soit en mesure de stocker des notions de droits POSIX.

             

            Un système de fichiers peut ou non être capable de mémorisés des droits (c'est par exemple possible avec de l'ext3 ou de l'ext4 mais pas avec de la fat32 ou de la ntfs). Les droits réellement mémorisés dans le système de fichiers peuvent différer de la représentation POSIX (c'est par exemple le cas de l'ext3 comme le montre la commande lsattr, pour plus de détail on pourra consulter cet article).

             

            La représentation de droits POSIX est créé au moment de déclencher la commande mount. Elle est donc associée au VFS et créée en mémoire en se basant sur les informations mémorisées dans les inodes ou conformément aux options de montge.

             

            Il reste toutefois possible de forcer cette représentation au moment de sa création (ie au moment de monter ce système de fichiers).  Ceci consiste à passer des options au moment de monter le périphérique (voir options uid, gid, umask, référencées dans cet article). Toutefois, si l'on change les droits associés à de telles fichiers, ces informations ne seront pas mémorisées et seront perdues la prochaine fois que ce système de fichiers sera monté.

            Commandes d'administration

             

            La commande chmod peut être utilisée de deux manières :

            • Avec une syntaxe explicite : elle ne modifie que certains droits.
              • On définit la portée (pour qui les droits seront modifié)
                • u : l'utilisateur propriétaire,
                • g : le groupe propriétaire,
                • o : les autres,
                • a : tout le monde (a = u + g +o).
              • On précise si l'on ajoute ou si on retire des droits
                • + pour en ajouter,
                • - pour en retirer.
              • On précise quel(s) droit(s) est (sont) modifié(s) :
                • r : lecture,
                • w : écriture,
                • x : exécution,
                • s : bit Set-UID, Set-GID selon que la portée est "u" ou "g",
                • t : sticky bit.
            • Avec la syntaxe octale, composée de 4 chiffres compris entre 0 et 7 .
              • Le chiffre des milliers est utilisé pour définir si le sticky bit, le bit Set-UID et le bit Set-GID sont activés
                • Il est souvent sous-entendu car on active rarement ces droits.
              • Les chiffres suivants sont utilisés comme suit :
                • centaines : droits de l'utilisateur propriétaire,
                • dizaines : droits du groupe propriétaire,
                • unités : droits des autres.
              • La valeur comprise entre 0 et 7 est issue des droits activés et désactivés :
                • pour le chiffre des milliers :
                  • 4 : bit set-UID,
                  • 2 : bit Set-GID,
                  • 1 : sticky bit,
                  • on somme le tout pour en déduire le chiffre des milliers. Par exemple 7 = 4 + 2 + 1 revient à activer simultanément les trois droits.
                • Pour le chiffre des centaines, des dizaines, des unités :
                  • 4 : lecture,
                  • 2 : écriture,
                  • 1 : exécution,
                  • on somme le tout pour en déduire les droits (par exemple 5 = 4 + 1 correspond à activer les droits en lecture et en exécution, et à désactiver les droits en écriture)

            Le tableau ci-dessous donne quelques exemples d'utilisation de la commande chmod.

             

            CommandeRôle

            ls -l /home/toto/fichier.txt

            Affiche les droits associés à /home/toto/fichier.txt

            chown toto /home/toto/fichier

            chown toto:users fichier

            chown -R toto:users /home/toto

            toto devient l'utilisateur propriétaire du fichier /home/toto/fichier

            idem et users devient groupe propriétaire

            idem sur le dossier /home/toto

            chmod u+r fichier

            chmod g+w fichier

            chmod o+x fichier

            chmod a+rwx fichier

            chmod u-rw fichier

            chmod -R u+rw /home/toto

            Donne (+) les droits en lecture (r) à l'utilisateur propriétaire (u)

            Donne (+) les droits en écriture (w) au groupe propriétaire (g)

            Donne (+) les droits en exécution (x) aux autres (others) (o)

            Donne (+) les droits rwx à tout le monde (all) (a = u + g + o)

            Retire (-) les droits rw à l'utilisateur propriétaire

            Donne (+) les droits rw à l'arborescence (-R) /home/toto au propriétaire

            chmod 470 fichier

            chmod 640 fichier.txt

            chmod 755 script.sh

            Attribue les droits rwx uniquement à l'utilisateur. Active le bit Set-UID.

            Attribue les droits rw à l'utilisateur, r au groupe, aucun aux autres.

            Attribue les droits rwx à l'utilisateur, rx au groupe et aux autres

             

            Les commandes chown et chgrp requièrent des droits root.

            La commande chmod requiert des droits root si on est pas propriétaire du fichier.

             

            Pour aller plus loin

             

            Certains fichiers ont pour propriétaire (ou groupe propriétaire) un numéro, est-ce normal ?

             

            Non, cela signifie que l'application ne parvient pas à déterminer l'UID ou le GID associé au fichier pour le substituer par  un login ou un nom de groupe. En d'autres termes, l'UID (respectivement le GID) associé à ce fichier n'est pas référencé dans /etc/passwd (respectivement /etc/group). Les droits associés au propriétaire (respectivement au groupe propriétaire) sont alors inexploitables.

             

            Si un fichier est associé à un utilisateur et un groupe qui n'existent plus, il sera typiquement dans cette situation.  Cela peut également si le fichier appartient à un utilisateur itinérant et que le serveur NIS tombe.

            Mise en évidence

             

            Pour mettre en évidence ce phénomène, on peut :

            1. créer un utilisateur "toto",
            2. regarder l'UID associé à l'utilisateur "toto",
            3. regarder le GID associé à l'utilisateur "toto",
            4. basculer dans le profil toto,
            5. créer un fichier "toto.txt",
            6. regarder les droits affectés à "toto.txt",
            7. quitter le profil toto,
            8. supprimer l'utilisateur toto,
            9. regarder les droits affectés à "toto.txt"

            Voici les commandes linux correspondantes, à taper dans un terminal root :

             

            adduser toto

            grep toto /etc/passwd

            grep toto /etc/group

             

            On voit par exemple que toto à l'UID 1001 et le groupe toto a le GID 1001 (ce nombre peut être différent sur votre système en fonction des utilisateurs qui ont été créés par le passé). Lançons à présent un shell toto, créeons le fichier toto.txt et regardons les droits qui lui sont associés :

             

            su - toto

            touch ~/toto/toto.txt

            ls -l ~toto/toto.txt

            logout

             

            On quitte le shell de toto et on supprime cet utilisateur. Puis on regarde les droits associés à ses anciens fichiers. On constate en outre que ses fichiers n'ont pas été supprimés. Effectivement, ceci est le rôle de la commande "rm" et non userdel. En effet, supprimer un utilisateur ne signifie pas que l'on veut nécessairement supprimer ses fichiers.

             

            userdel toto

            ls -l ~toto/toto.txt

             

            On s'aperçoit que comme toto (ni le groupe toto) n'est référencé dans /etc/passwd (et dans /etc/group), la commande ls ne parvient plus a retrouver à quoi correspondent l'UID et le GID 1001.

            Est-ce grave ?

             

            Voici les conséquences immédiates.

            • Certains utilisateurs peuvent ne plus pouvoir accéder à ces fichiers. En effet, s'ils passaient par la couche de droits associée au groupe propriétaire.
            • Un fichier qui était accessible par les droits associés "aux autres" (o) restent inchangés. Un document qui était accessible de cette manière reste donc accessible de la même manière.
            • Globalement, si un utilisateur n'avait pas accès à un tel fichier, comme les droits ont globalement été diminués, il n'y a toujours pas accès. Ainsi un fichier confidentiel ne peut pas être récupéré suite à ce genre de problème.

            Par la suite, cela peut être catastrophique surtout si les fichiers de toto sont confidentiels. Pour mettre cela en évidence, créons un utilisateur titi, examinons son UID et les droits associés à toto.txt :

             

            adduser titi

            grep titi /etc/passwd

            grep titi /etc/group

             

            Comme l'utilisateur toto vient d'être supprimé, titi a récupéré l'UID que toto utilisait. Examinons les droits associés à toto.txt :

             

            ls -l ~toto/toto.txt

             

            Comme titi s'est accaparé l'UID de toto, le fichier toto.txt lui appartient ! Pour éviter cela, il aurait fallu au moment de créer titi lui attribuer un autre UID, ou réattribuer les fichiers de /home/toto à un autre utilisateur (par exemple root).

             

            Comment corriger cela ?

             

            • Si le fichier appartient à un utilisateur ou un groupe itinérant encore existant il faut simplement réparé le serveur NIS.
            • Si le fichier est associé à un groupe ou à un utilisateur qui n'existe plus, il faut le réattribuer à un utilisateur qui existe (grâce à la commande chown).
              • S'il s'agit d'un utilisateur qui a disparu, il faut que ce changement de propriétaire soit fait avec l'accord de la personne morale à laquelle appartenait ce fichier.

             

            Pourquoi Linux utilise-t'il des UID et des GID ?

             

            Dans la question "Comment sont mémorisés les droits sous Linux ?", nous avons vu que les droits étaient mémorisés dans les inodes. Si l'on stocke dans chaque entier pour l'utilisateur propriétaire (4 octets par exemple). Si on devait stocker le login "mando" on aurait les inconvénients suivants :

            • plus coûteux en terme d'espace : la chaîne "mando" coûte 5 caractères (à raison d'un octet par caracratère) + 1 octet pour stopper la chaîne, soit un total 6 octets,
            • plus compliqué à mettre en œuvre : gérer une chaîne de taille variable (par exemple pour associer le login à un fichier) serait plus complexe que gérer un espace de taille fixe (l'UID)
            • moins efficace : si on décide que l'utilisateur mando doit en réalité s'appeler toto, il suffit de corriger le fichier /etc/passwd pour corriger la conversion entre l'UID et le login.

            Sur le même principe, les groupes sont identifiés par un GID.

             

            Que faire si les droits POSIX ne permettent pas de définir une politique d'accès assez fine ?

             

            Les droits ACL (Access Control List) sont une généralisation des droits POSIX et permettent de définir une politique d'accès plus complexe. On utilise pour cela les commandes getfacl (get file access control list) et setfactl (set file access control list). Celles-ci sont expliqués ici. On pourra également consulter les pages de man associées :

             

            man getfacl

            man setfacl

             

            On peut également affiner les politique grâce à SELinux (System Enhanced Linux) qui permet de définir une politique d'accès dans des contextes particuliers. Par exemple, on peut restreindre l'accès à un fichier si et seulement si une application est lancée. Pour plus de détails :

             

            man selinux

             

            Quoi qu'il en soit, pour qu'un fichier soit accessible il faut réussir à traverser l'ensemble des droits qui lui sont associés :

            • droits au niveau du système de fichiers (voir commandes  lsattr et chattr pour un système de fichiers ext3 ou ext4),
            • droits au niveau du VFS (voir options ro et rw au moment de déclencher la commande mount),
            • droits POSIX (voir options uid, gid, umask au moment de déclencher la commande mount, voir commandes ls, chown, chgrp, chmod pour les gérer), que seul root peut ignorer,
            • droits SELinux (voir commandes chcon, restorecon, chcat...).

            J'ai une permission refusée (permission denied) et je ne comprends pas pourquoi, que faire ?

             

            Supposons que le fichier /home/toto/plop.txt soit récalcitrant. Vérifiez que vous parvenez à traverser chacune des couches de droits associées à ce fichier.

            Droits au niveau du système de fichiers

             

            La commande lsattr permet de récupérer les droits enregistrés au niveau d'un système de fichiers ext3. Normalement tous ces droits sont désactivés quel que soit le fichier que vous considérez sur un système Linux standard. Si vous avez été piraté, certains fichiers corrompus (commandes sensibles comme ps, netstat etc...) peuvent avoir ces droits modifiés afin de ne pas être écrasés par une mise à jour tant que l'administrateur ne s'en rendra pas compte !

             

            (root@silk) (~) $ lsattr /home/toto/plop.txt

            ------------------- plop.txt

             

            Droits au niveau du VFS

             

            Le fichier /home/toto/plop.txt est stocké dans /home, donc dans la partition dédiée à /home si lors de l'installation on a mis en place une partition dédiée /home. Sinon ce fichier est sur la partition associée à /. Pour plus de détails regardez l'article sur le partitionnement.

             

            Un système de fichiers (partition de disque dur, média USB, disque CD, partage réseau, ...) peut être monté en lecture seule (ro pour read only). Notez que même root ne peut aller à l'encontre de ces droits : un système de fichiers monté en lecture seul ne peut jamais être modifié par qui que ce soit. Pour le modifier, il faut le remonter en lecture écriture.

             

            Même si les notations se ressemblent, cette couche de droite ne doit pas être confondue avec la couche de droits POSIX. On voit notamment que ce ne peut pas être la même couche de droit puisqu'il n'y a pas de notion de portée : le système de fichiers est soit accessible en lecture seule pour tout le monde, soit accessible en lecture écriture pour tout le monde.

             

            Pour plus de détails regardez l'article sur comment monter un périphérique sous Linux. On peut vérifier les droits associés à chaque système de fichiers grâce à la commande mount :

             

            (mando@silk) (~) $ mount
            /dev/sda6 on / type ext3 (rw,errors=remount-ro)
            tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
            proc on /proc type proc (rw,noexec,nosuid,nodev)
            sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
            udev on /dev type tmpfs (rw,mode=0755)
            tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
            devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
            /dev/sda7 on /home type ext3 (rw)
            /dev/sda2 on /mnt/windows type fuseblk (rw,allow_other,blksize=4096)
            fusectl on /sys/fs/fuse/connections type fusectl (rw)
            binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw,noexec,nosuid,nodev)

             

            Ici /home est sur une partition dédiée (/dev/sda7) montée en lecture écriture (rw). Ainsi /home/toto/plop.txt est modifiable aux niveaux de cette couche de droits.

             

            Droits POSIX

             

            Les droits POSIX s'examinent avec la commande ls -l. Il faut au préalable déterminer quel jeu de droits sont exploitables.

             

            Exemple :

             

            (mando@silk) (~) $ whoami
            mando
            (mando@silk) (~) $ groups
            mando dialout cdrom floppy sudo audio video plugdev fuse
            (mando@silk) (~) $ ls -l /home/toto/plop.txt
            -rw-r--r-- 1 toto toto 0 14 janv. 15:20 /home/toto/plop.txt

             

            Ici le fichier appartient à toto, groupe toto, donc mando utilisera la troisième série de droits (r--). Il pourra donc uniquement lire le contenu de plop.txt.

             

            Notez que l'on ne peut afficher les droits associés à plop.txt que si l'on peut entrer à l'intérieur du répertoire /home et du répertoire /home/toto (droits rx). Il faut raisonner ainsi pour chaque argument. Par exemple la commande suivante :

             

            cp /home/mando/pouet.txt /home/toto/plop.txt

             

            ... ne peut marcher que si on a les droits rx sur /home, /home/mando, /home/toto, les droits r sur pouet.txt et les droits w sur /home/toto ou /home/toto/plop.txt.

             

            Le mot de passe est stocké dans /etc/passwd, que faire ?

            1. Ouvrez un shell associé à l'utilisateur dont le mot de passe est stocké dans /etc/passwd.
            2. Remplacez dans /etc/passwd le mot de passe par le caractère x.
            3. Lancez dans le shell de l'utilisateur incriminé la commande passwd (ou la lancer root pour cet utilisateur).
            4. Comme le "x" est positionné, passwd écrira le mot de passe dans /etc/shadow. Sinon il aurait écrit par dessus l'ancien mot de passe dans /etc/passwd.

            J'ai oublié mon mot de passe, que faire ?

             

            On se place ici dans le contexte d'un mot de passe associé à un utilisateur local à la machine.

            Quelqu'un a les droits administrateurs sur la commande passwd (root ou sudoer)

             

            Supposons que toto ait oublié son mot de passe. Le plus simple est de demander à quelqu'un qui connaît le mot de passe root  (ou sudoer sur la commande passwd) de taper la commande suivante :

             

            passwd root

             

            Un administrateur n'a pas besoin de connaître le mot de passe d'un utilisateur pour le modifier.

             

            J'ai oublié mon mot de passe root !

            Principe

             

            Une fois le système live démarrer, il s'agit d'accéder à la partition de disque dur qui contient le fichier /etc/passwd associé au système linux du disque dur. Pour aborder ce tutoriel il est recommandé d'avoir lu au préalable le tutoriel sur les périphériques et sur nano. Toute l'idée est qu'on est root au sens du système live. On peut donc monter n'importe quel système de fichier local à la machine avec les droits que l'on souhaite.

             

            Méthode 1 : accès direct

             

            Supposons que par exemple /etc/passwd soit stocké sur la partition /dev/sda1. On tape en root :

             

            mkdir -p /mnt/linux

            mount /dev/sda1 /mnt/linux

            nano /mnt/linux/etc/passwd

             

            système live !).Notez que le fichier modifié est bien /mnt/linux/etc/passwd (fichier du système linux disque dur) et non /etc/passwd (fichier du système live !). On enlève le "x" associé à l'utilisateur root (voir section sur /etc/passwd), puis on redémarre la machine. La ligne ressemble alors à ceci :

             

            root::0:0:root:/root:/bin/bash

             

            On sauve et on quitte (ctrl x). On quitte proprement :

             

            umount /mnt/linux

            reboot

             

            On redémarre normalement (pas sur le système live) et on passe en mode texte (ctrl alt f1). On s'identifie en root. Comme le x n'est pas positionné, le terminal root. On repositionne le caractère x :

             

            nano /etc/passwd

             

            ... de sorte à avoir la ligne initiale, typiquement :

             

            root:x:0:0:root:/root:/bin/bash

             

            Si on ne le fait pas et que root tape directement la commande passwd, son mot de passe sera stocké dans /etc/passwd (avec les inconvénients que cela implique, voir sections sur /etc/passwd et "Le mot de passe est stocké dans /etc/passwd, que faire ?"). Comme on est identifié en root on peut à présent changer le mot de passe de n'importe qui, en particulier root :

             

            passwd root

             

            Méthode 2 : par chroot

             

            Cette méthode est plus générique et soumise aux mêmes contraintes. Toute l'idée est de reconstituer dans le répertoire /mnt/linux l'arborescence qui aurait figuré dans / si on avait démarré normal, puis de positionner le shell au niveau de /mnt/linux. Cette démarche se généralise pour réparer n'importe quel système Linux qui ne démarre plus (on pourra par exemple en voir un exemple ici).

             

            On suppose que le système Linux comporte une partition / (qu'on suppose ici être /dev/sda1) qui contient /etc, /bin et /sbin (si ce n'est pas le cas il se peut que vous deviez faire quelques montages supplémentaires).

             

            Une fois le système live CD démarré, lancez un terminal, passez en root, et tapez les commandes suivantes :

             

            mkdir -p /mnt/linux

            mount /dev/sda1 /mnt/linux

            chroot /mnt/linux

             

            À présent, / est positionné à la place de /mnt/linux. Ainsi le fichier que l'on aurait appelé /mnt/linux/etc/passwd est représenté dans le shell associé au chroot par /etc/passwd. De même, si on lance la commande passwd (/usr/bin/passwd), ce sera l'exécutable du disque dur qui sera lancé. En d'autres termes, tout se passe comme si on avait démarré normalement sur le disque dur. Il ne reste plus qu'à changer le mot de passe :

             

            passwd

            exit

            umount /mnt/linux

            reboot

             

            Cela signifie-t'il qu'on peut facilement s'introduire dans un système Linux ?

             

            Avant tout, retenez bien que cette procédure ne peut être exécutée que dans un cas très particulier : vous avez accès physiquement à la machine pour la faire démarrer sur un autre système d'exploitation (par exemple un live USB ou un live CD). Ceci ne remet donc pas en cause la sécurité du système Linux en tant que tel car un serveur est généralement dans une salle serveur fermée à clé. Ainsi seules les personnes autorisées à entrer dans le local peuvent utiliser cette approche.

             

            Si la machine en question est un portable et contient des données sensibles, vous devriez peut-être chiffrer vos données grâce à LVM et lukefs.

             

             

            ExtensionCompressionDécompressionPaquet(s) requisRemarque sur l'archive
            .zip zip archive.zip fichiers unzip archive.zip zip unzip Compresse n fichiers
            .rar unrar e archive.rar unrar ou unrar-free   Compresse n fichiers
            .gz gzip fichier gunzip archive.gz gzip Compresse 1 fichier
            .bz2 bzip2 fichier bunzip2 archive.bz2 bip2 Compresse 1 fichier
            .tar tar cvf archive.tar fichiers tar xvf archive.tar tar Réunit n fichiers (sans compression)
            .tar.gz ou .tgz tar cvzf archive.tar fichiers tar xzvf archive.tgz tar gzip Compresse n fichiers
            .tar.bz2 ou .tbz2    tar cjvf archive.tbz2 fichiers   tar xjvf archive.tbz2   tar bzip2 Compresse n fichiers

             

            Po
            .
            X
             
             
             
             
             

            You havecharacters left.