Gestion des utilisateurs et des droits

Utilisateurs et groupes

La majorité des employés n’a pas besoin d’un compte serveur. Les comptes locaux sont réservés aux personnes qui devront modifier des fichiers sur le serveur. Il peut parfois être nécessaire d’expliquer à un manager ou à un directeur que le mot de passe du serveur n’est pas un symbole de prestige, et qu’il peut faire plus de mal que de bien dans les mains d’un non professionnel.

Évidemment, les employés doivent s’identifier pour lire et envoyer du courrier électronique, mais pour cela, il n’est pas nécessaire d’avoir un compte local. La base de données des mots de passe utilisée pour le courriel sera traitée dans la section Lightweight Directory Access Protocol (LDAP) du chapitre Bases de données.

Outre le fait de posséder un compte et le nom d’utilisateur qui va avec, les utilisateurs appartiennent à un ou plusieurs groupes. Le premier de ces groupes est nommé le groupe primaire, en anglais primary group ou login group. C’est celui qui est attribué aux nouveaux fichiers et répertoires si l’utilisateur ne spécifie pas explicitement un autre groupe, et c’est le groupe qui est attribué aux processus lancés par l’utilisateur. Sur la majorité des systèmes Unix modernes, le groupe primaire est un groupe personnel qui porte le même nom que le nom d’utilisateur ; cela contribue à protéger la confidentialité du répertoire personnel, par exemple.

L’administrateur système est libre dans la conception et la distribution de ces groupes, selon les demandes et les exigences du système en question. Par exemple, sur un serveur web, des groupes peuvent exister pour les développeurs et les graphistes, mais sur un serveur intranet, les groupes sont définis en fonction de l’accès aux scanners et imprimantes ; l’administrateur d’un ordinateur de bureau peut vouloir limiter l’accès aux médias externes en créant des groupes pour les utilisateurs qui ont le droit d’utiliser les ports USB et le lecteur DVD.

Sur certains systèmes Unix, dont la famille BSD et les systèmes basés sur Red Hat Linux comme CentOS, il existe un groupe nommé...

Droits d’accès

Quand on parle des droits d’accès, ou droits d’utilisateur, sur les systèmes Unix, on parle généralement du système traditionnel : un fichier ou une application appartient à un utilisateur et à un groupe, un utilisateur peut appartenir à plusieurs groupes et l’administrateur système peut manipuler tout ça pour arriver à la combinaison désirée de droits en lecture, écriture et exécution pour chaque utilisateur.

Cependant, depuis longtemps (FreeBSD 4.0-CURRENT et noyau Linux 2.5.46, publiés en 2002 tous les deux), un système existe pour compléter le système traditionnel quelque peu limité : Access Control Lists ou simplement ACL (Listes de Contrôle d’Accès). Ce système a été publié dans le document POSIX 1003.1e draft 17, et même si ce document n’a jamais été promu comme une norme, il a fait en sorte que les ACL soient implémentées dans les noyaux Unix et que le support pour cette fonctionnalité soit activé par défaut.

Celui qui travaille avec Unix, comme administrateur ou comme utilisateur, ne peut échapper à l’apprentissage du système de droits d’accès traditionnel : ce système est toujours la base de l’autorisation sous Unix. Les ACL peuvent introduire un étalement et une simplification bienvenus du contrôle, mais il est impossible de les implémenter sans une connaissance et une compréhension solides du système traditionnel.

Il est important de comprendre que les droits d’accès sont toujours relatifs, c’est-à-dire qu’un utilisateur ayant les droits corrects pour l’accès à un fichier, mais pas pour le répertoire contenant ce fichier, n’arrivera pas à accéder au fichier. 

Les droits d’accès d’un fichier peuvent être modifiés seulement par le propriétaire de celui-ci et par l’utilisateur root.

Limitation d’accès root

Une erreur de frappe est vite arrivée, et les logiciels comportent parfois des bogues. Tout cela peut s’avérer problématique si cela entraîne par exemple la suppression de fichiers ou leur ineccessibilité.

Or si ces problèmes arrivent à l’utilisateur root, les conséquences peuvent être désastreuses ; en effet, possédant les droits de modification partout sur le système, root a la capacité de rendre le système inutilisable ou inaccessible. C’est pour cette raison que les daemons sont exécutés sous leur propre nom d’utilisateur actuellement, et non plus sous le nom de root.

De plus, le nom d’utilisateur root est le même sur tous les systèmes Unix, ce qui fournit déjà aux attaquants potentiels la moitié des informations nécessaires pour obtenir l’accès administrateur sur le système.

Voilà pourquoi il est fortement recommandé de limiter l’utilisation du compte root et de bloquer complètement l’accès direct à ce compte.

freebsd$ which sudo 
freebsd$ 
 
debian$ which sudo 
debian$ 
 
centos$ which sudo 
/bin/sudo 
centos$