15 octobre 2008

Gestion des utilisateurs

Général

Chaque utilisateur possède :

• identifiant
• mot de passe
• uid : numéro d’utilisateur
• gid : numéro de groupe
• un répertoire “home”
• un shell de démarrage par défaut

Un groupe :

• un nom
• un gid

Type d’utilisateurs :

• root (uid=0) : pas concerné par les droits
• application (uid > 0, et < à 500)

par exemple : lp, apache, … => limiter l’accès des applications sur les fichiers

Fichiers importants :

• /etc/login.defs : politique employée pour les mots de passe
• /etc/nsswitch.conf : mode d’authentification qu’on va utiliser => utile pour LDAP ou NIS
• /etc/passwd
• /etc/group
• /etc/shadow

Le fichier /etc/passwd

Il suit la chaîne suivante :

login:passwd:pid:gid:gecos:homedir:shell

Le fichier /etc/group

Il suit la chaîne suivante :

group:passwd:gid:logins

Le fichier /etc/shadow

Il suit la chaîne suivante :

login:passwd:last:min:max:inactif:expire:drapeau

inactif : durée d’inactivité “légale” d’un compte

Gestion d’utilisateurs, groupe et mots de passe (mode assisté)

On fait les commandes suivantes :

• useradd/del/mod
• groupadd/del/mod
• passwd

Utiles

Pour les utilisateurs :

• id => uid, gid
• su ou su -s => pour être root sans limite de temps

Sur les fichiers :

• chfn : changement gecos

• chsf : changement de shell

• makepasswd

• openssl passwd

• crypt

Compilation du noyau

Installation

Pour installer son noyau il faut :

• Récupérer le noyau :

wget http://domaine.com/noyau.tar.gz

• Se placer au bon endroit :

cd /usr/src/linux2.X

• tar xvf linux-2.X.YY.tar.gz
• make config, puis question Y/m/n
  • Y : compiler le noyau
  • m : compiler en module
  • n : ne rien faire

Compilation du noyau

Compilation du noyau :

make clean && make dep && make image

Compilation des modules :

make module

Installation :

make install

Architecture de réseau sous UNIX

Uniquement pour des réseaux de confiance (pas très sécurisé, voire pas du tout).

Solution X-Window

L’objectif est de pourvoir à un ensemble d’utilisateur un accès réparti à leurs données.

Serveur (fichiers, etc.)

	Client X11
 
        +----+
        |    |-------- Client
       /|    |<br/>
      / |    | <br/>
     /  +----+  <br/>
  Client	Client
(Serveur X11)

Il y a deux façons pour se faire :

• terminal texte (getty)
• terminaux graphiques : Terminaux X sur lequel un serveur X11 est installé, ce qui implique au minimum d’avoir une carte réseau

X11 est le protocole standard client/serveur (graphique) d’UNIX. Pour s’y connecter on utilisera les sockets (via TCP/IP).

X-Window s’est inspiré du travail de Rank Xerox nommé WIMP( = Window, Icons, Menus, Pointer).

Un des clients indispensable à un serveur X est le Window Manager qui gère le déplacement des fenêtres.

Contrôle d’accès

Deux méthodes :

• Clé de session : cookie. On manipule alors les cookies avec la commande xauth
  • xauth list
  • xauth add
• xhost : manipuler l’accès des machines sans les bons cookies

Semaine prochaine nous utiliserons la seconde méthode.

Démarrage d’un terminal X

• Chargement des paramètres réseau puis récupération du système ( NFS + DHCP / BOOTP )
• Démarrage du serveur X11

Côté client : XDMCP (X Display Manager Control Protocol).

XDMCP dispose de 2 modes :

• mode direct : X -query IP [:n°]
• mode indirect : indirection via une autre machine

Avantages

• Fiabilité (à part la carte réseau, rien de spécial pour les terminaux X
• Confort de travail : juste l’écran, donc pas de bruits de la tour, etc.
• Gestion centralisée des comptes (facile pour l’administrateur)
• Administration aisée des TX

Inconvénients

• Charge réseau : pénible si pas de bande passante suffisante
• Charge processeur : si plus de 100 équipements qui tournent à plein régime sur une machine pas assez suffisante pour tenir la charge, il y aura des soucis de puissance
• Pas de périphériques locaux : pas de clé USB, disquettes, etc.
• Sécurité : ça marche sur réseau de confiance, mais pas évident à gérer. Les données passent en clair sur le réseau
• Prix : pour le serveur …

NFS / NIS : solution distribuée

Partage des fichiers avec NFS (Network File System)

Architecture client / serveur : le client veut les fichiers, le serveur les donne. Comme les fichiers sont un peu partout, chaque machine est à la fois client et serveur.

Le serveur exporte des répertoires (/etc/export) vers machines nommées explicitement via leurs IPs.

Le client monte ses répertoires (des sytèmes de fichiers de type NFS).

La sécurité vient seulement des identifiants … donc si on accède avec une machine en tant que ROOT, NFS croit qu’on a tout les droits sur les fichiers.

NFS, côté serveur

3 démons permettent à NFS de tourner :

• rpc.nfsd : exportation de fichiers (requêtes de transfert de fichiers)
• rpc.mountd : demande de montage des clients (requêtes de montage)
• rpc.lockd : vérifier à ce que le fichier reste cohérent (verrouillage de fichiers lorsqu’ils sont utilisés)

NFS peut tourner en UDP ou en TCP.

La vérification des droits d’accès se fait en 2 temps :

• Le portmapper (démon portmap) associant un numéro de port à un service RPC (Remote Procedure Call) peut vérifier grâce à TCPwrappers que la machine a le droit d’accès
• Si ce droit est acquis, mountd vérifie que l’entrée dans /etc/exports existe bien. Finalement nous travaillerons principalement dans ce fichiers pour l’ensemble des droits

1 exemple de ligne dans /etc/exports

/CDROM-ro,access######130.79.92.15,anon0

NFS, côté client

Commande manuelle :

mount serveur:/rep /point_de_montage

Paramètres d’écriture dans NFS

Options pour l’export de fichiers :

• rsize,wsize : taille des blocs transmis par NFS. Exemple : 8ko (bon compromis)
• hard (si prob réseau, l’appli fige) / soft ( = un timeout, si aucune réponse au bout d’un moment, il s’arrête et ne cherche pas à comprendre)

Les démons côté client :

• rpc.lockd
• rpc.statd : notifieur de redémarrage, il permet de restaurer les locks au redémarrage

L’authentification par uid => aucune sécurité

La commande exportfs -a permet de (ré)-exporter toutes les entrées de /etc/exports.

NIS, Network Information Service

L’objectif est de centraliser les mots de passe.

Tout est dans ce fichier : /etc/nsswitch.conf ; c’est l’ordre d’authentification.

NIS a été crée par SUN sous le nom de YellowPages mais BT (Britisch Telecom) avait déjà déposé le nom.

Authentification système à plat contravenant à LDAP.

Architecture client/serveur

Pour un accès rapide, la base de données est construite avec les fichiers ASCII du système : /etc/passwd et /etc/shadow.

Pour éviter un trou de sécurité, il faut bloquer l’accès à la commande permettant de voir les mots de passe chiffrés.

Les fichiers sont donc hachés au format [n|g]dbm (n ###### new, g gnu).

Sur le serveur on va créer un domaine et des sous domaines, mais rien à voir avec les domaines réseaux DNS.

+::::::

Ce code dit d’aller sur le serveur NIS pour s’authentifier (centralisation de l’authentification)

NYS : corrige les failles de sécurité

NIS+ : adapté aux réseaux de grande taille

NIS côté serveur

démon ypserv

éventuellement utilisé conjointement avec TCPwrappers comme pour NFS

Sécurité : /var/yp/secuevents

Configuration : /etc/ypserv.conf

Commande pour le peuplement de la base : ypinit-m (prend les trois fichiers nécessaires, les prépare, les mélanges, etc et peuple la base de données)

ypinit utilise un makefile spécifique : /var/yp/Makefile

Modifier les mots de passe : yppasswd

NIS, côté client

Commande démon ypbind

Fichier de configuration : yp.conf (nom de domaine puis adresse IP du serveur)

Étapes supplémentaires :

• Modifier nsswitch.conf
• Ajouter +:::::: à la fin de /etc/passwd

ypcat : affichages des tables en ASCII

ypmatch

FAT (File Allocation Table)

mount de dir type options