Sécurité Sous Unix

Sécurité sous Unix
Introduction : sécurité des systèmes d’exploitation Sécurité sous Unix
1 Introduction : sécurité des systèmes d’exploitation
2 Sécurité sous Unix

Utilisateur
Root
groupes
Invocation contrôlée
Structure de fichiers
Gestion des droits d’accès
Journaux d’audit
2/36

Utilisateur
Root
groupes
Journaux d’audit
3/36
Sécurité du système d’exploitation

C’est la base informatique de confiance
Quels sont les mécanismes de sécurité implantés dans le
système d’exploitation
Comment ces mécanismes sont-ils gérés ?
Quelle assurance avons-nous envers ces mécanismes ?
4/36
La base de la sécurité de la plupart des systèmes d’exploitation

repose sur ces éléments :
L’information sur les utilisateurs (sujets) sont contenus dans

des comptes d’utilisateurs
Les privilèges accordés à un utilisateur sont définis par
rapport à ce compte
L’identification et l’authentification vérifient l’identité d’un
utilisateur, permettant au système d’exploitation d’associer les
privilèges de l’utilisateur avec tout processus démarré par ce
dernier
5/36
La base de la sécurité de la plupart des systèmes d’exploitation

repose sur ces éléments :
Les permissions sur les ressources (objets) sont définies par

l’administrateur et/ ou par le propriétaire de la ressource
Lorsque vient le temps d’accorder ou de refuser l’accès à une
ressource, le système d’exploitation décidera en fonction de
l’identité de l’utilisateur, de ses privilèges et des
permissions de l’objet
6/36
La sécurité d’un SE s’appuie autant sur la prévention d’actions non

autorisées que sur la détection
Même si un adversaire astucieux brise nos défenses, il faut

quand même s’en rendre compte !
C’est pourquoi les SE conservent un journal d’audit sur les
événements qui ont un impact sur la sécurité
7/36
Les meilleurs mesures de protection ne servent à rien si elles sont

mal installées ou configurées
La plupart des SE ont des options par défaut à l’installation

qu’il est dangereux de conserver
De nouvelles attaques peuvent menacer même un système
bien installé et configuré.
C’est pourquoi il faut se tenir au courant des derniers
développements, et des découvertes de nouvelles failles grâce
aux études des équipes d’intervention informatique d’urgence
(en anglais CERT)
8/36
En résumé, un cadre sécuritaire pour l’implantation d’un système

d’exploitation devrait inclure :
un mécanisme de ”login” dans un compte d’utilisateur

un contrôle d’accès sur les ressources
une notion de trace d’audit
une bonne installation et configuration
9/36

Utilisateur
Root
groupes
Journaux d’audit
10/36
Utilisateur
Utilisateur
Un compte d’utilisateur est identifié par un nom d’utilisateur et

authentifié par un mot de passe.
Les mots de passe ne sont pas stockés en clairs, ils sont
chiffrés (par l’algorithme crypt )
Les utilisateur sont stocké dans le fichier /etc/passwd
Les mots de passe chiffrés sont contenus dans le fichier
/etc/shadow
11/36
Utilisateur
le format standard du contenu du fichier /etc/passwd est le

suivant :
Nom d’utilisateur:x:UID:GID:userinfo:homeDirectory:shelltype
le format standard du contenu du fichier /etc/shadow est le
suivant :
Nom d’utilisateur: Mot de passe chiffré:autresinformations
12/36
Utilisateur
Un utilisateur est désigné par un nom d’utilisateur, mais

représenté par un identifiant d’utilisateur (en anglais UID).
Certains UID sont réservés par le système
(0 :root,1 :daemon. . . )
Dans chaque système Unix, il y a un utilisateur qui a des
privilèges spéciaux, le super-utilisateur (root)
13/36
Root
Super-utilisateur : root
Le super-utilisateur peut à peu près tout faire :

Utilisé par le système pour certains tâches essentielles
comme le ”login”, l’enregistrement du journal d’audit ou
l’accès E/S.
Presque tous les mécanismes de contrôle sont désactivés
pour cet utilisateur.
Peut changer l’horloge, devenir un autre utilisateur sans le
mot de passe.
Ne peut pas déchiffrer les mots de passe des utilisateurs
(ouf !)
Pas pour usage personnel de l’administrateur !
14/36
Root
Tous ces pouvoirs rend ce compte très attrayant pour un adversaire
Toutes les précautions doivent être prises pour empêcher

quelqu’un de devenir un super-utilisateur sans autorisation.
Permission sur les fichiers /etc/passwd et /etc/group
Mascarade sur le programme su
Séparation des tâches pour éviter d’utiliser l’utilisateur root
15/36
groupes
Groupes
Un utilisateur appartient à un ou plusieurs groupes.

Permet de simplifier les décisions sur le contrôle d’accès
Tous les utilisateurs appartiennent à un groupe primaire,
défini à la création de l’utilisateur
Un utilisateur peut appartenir à plusieurs d’autres groupes,
dits secondaire
L’identifiant du groupe primaire se trouve dans /etc/passwd
Les groupes sont décrits dans le fichier /etc/group
Certains identifiants de groupes sont réservés
Exemple d’une ligne de /etc/group
cartoons:*: 999: bugs, dafy, elmer, sam
16/36
Par défaut, un programme s’exécute avec les privilèges de

l’utilisateur qui l’a démarré.
Exemple : Votre éditeur de texte ne pourra pas ouvrir un
fichier dont vous n’avez pas les droits
Certaines opérations requiert des privilèges plus élevé que celui
de l’utilisateur.
Un mécanisme permet à certains programmes d’assumer, pour
le temps de cette opération, une autre identité.
Un programme ayant l’attribut SUID (substitution
d’utilisateur) s’exécutera avec l’identité du propriétaire du
programme (et non pas celle de l’utilisateur)
Exemples : passwd , login , at , su
17/36
Un programme ayant l’attribut SGID (substitution de groupe)

s’exécutera avec l’identité du groupe du programme
18/36
Il faudra valider que le programme utilisant la substitution

d’identité (ou de groupe) fasse exactement ce qu’il doit faire
et pas plus !
Faire attention lorsque vous attribuez la substitution
d’identité : uniquement pour les programmes de confiance
Attaque possible
Un appel a un terminal peut être dissimulé dans un programme
avec invocation controlée. Il sera possible pour l’attaquant d’avoir
accès à un terminal avec d’autres droits que les siens
19/36
Unix organise les fichiers dans une arborescence de fichiers et de
répertoires. Chaque entrée dans un répertoire est un pointeur sur
un inode, une structure de données contenant plusieurs champs,
dont :
Mode
Type de fchier et droits d’accès
uid Identifcateur de l’utilisateur propriétaire
gid Identifcateur du groupe propriétaire
atime Moment du dernier accès
mtime Moment de la dernière modifcation
itime Moment de la dernière modifcation de l’inode
blockcount
Taille du fchier
Emplacement physique du fichier sur le disque
20/36
Exemple de structure de fichiers :
drwxr-x--- 1 martinr chacours 1024 Jan 24 12: 00 .

dr-xr-xr-x 2 root wheel 1024 Jan 24 12: 00 ..
-rws--x--x 1 martinr chacours 5678 Jan 25 08: 44 addjoke*
-rw------- 1 martinr chacours 543 Jan 23 11: 43 jokes.txt
-rw-rw-r-- 1 martinr chacours 128 Jan 11 09: 23 readme
La première lettre indique le type de fchier -= fchier, d=

répertoire, c/ b= fchiers de périphériques
Les 9 caractères suivants indiquent les droits d’accès
L’identifcateur d’utilisateur est ”martinr”
L’identifcateur de groupe est ”chacours”
La taille suit, puis la date et l’heure, puis le nom du fchier
Noter les 2 premiers fchiers . et ..

21/36
Que peut- on déduire au niveau des droits d’accès ?

L’utilisateur martinr est le propriétaire de tous les fichiers
(sauf ..)
Le groupe chacours est le propriétaire de tous les fichiers
Le répertoire ”.” est libre d’accès pour martinr
Les membres du groupe chacours peuvent lister et parcourir
le répertoire, mais ne peuvent créer ou effacer de fichier.
Le répertoire ”..” appartient à l ’utilisateur root et au groupe
wheel. L’utilisateur martinr ne pourrait donc que le lister et
parcourir.
Le programme addjoke est libre d’accès pour son propriétaire,
et possède l’attribution de substitution d’utilisateur.
22/36

Conséquences du SUID :
Donc, à chaque fois que le programme sera démarré, il
possédera les privilèges de l’utilisateur ”martinr”, lui
permettant, par exemple, d’ajouter un enregistrement au
fchier ”jokes. txt”.
Le fichier ”readme” peut être lu et modifé par l’utilisateur
”martinr” et les membres du groupe ”chacours”, mais ne peut
qu’être lu par les autres.
23/36
La commande chmod
de modifier les droits d’accès associés à un fichier
Elle ne peut être exécutée que par le propriétaire du fichier
ou par le super-utilisateur.
C’est par cette commande qu’on peut :

Ajouter ou retirer un droit r/w/x au
propriétaire/groupe/autres
Activer/désactiver la substitution d’utilisateur
Activer/désactiver la substitution de groupe
24/36
La commande chown permet de modifier le propriétaire d’un

fichier,
La commande chgrp modifie le groupe
Ces commandes, combinées avec les attributs de substitution

d’identité, introduisent un grave problème.
Ce problème est résolu en limitant ces commandes.
25/36
Droits par défaut
Par défaut, les nouveaux fichiers reçoivent une permission Il est

possible, voire même souhaitable, d’ajuster ce comportement par
défaut, par la commande umask, qui permet de masquer des droits
d’accès pour les nouveaux fichiers.
Exemple :
umask 777 Bloque tous les accès (———)
umask 077 Ne conserve que les accès du propriétaire
umask 022 Retire la possibilité de modifier au groupe et
autres
26/36
Utiliser l’invocation contrôlée pour gérer l’accès à une

ressource sensible
Créer un nouveau UID qui possède la ressource et tous les

programmes qui ont besoin d’y accéder
Donner un accès (complet) seulement au propriétaire
Ajouter l’attribut de substitution d’utilisateur à tous les
programmes qui accèdent à la ressource
27/36
Un adversaire peut éviter certaines mesures de protection en

attaquant directement un périphérique.
Les périphériques sont représentés par des fichiers dans /dev.
Ils sont crées (par l’utilisateur root) à l’aide de la commande
mknod.
Quelques exemples : /dev/mem Image de la mémoire
physique /dev/tty Terminal
Si un fichier de périphérique permet la lecture ou l’écriture sur un
périphérique de mémoire, alors un adversaire peut parcourir la
mémoire et la modifier à sa guise.
Certains programmes doivent pouvoir accéder à ces
périphériques. Ils utilisent la substitution d’identité (Ex : la
commande ps).
L’accès en lecture ou écriture sur un fichier de terminal peut
aussi introduire un problème de sécurité.
28/36
Le montage de disques par la commande mount est susceptible à

une attaque de type ”Cheval de Troie”.
Un système de fichiers qui est monté comprend un fichier
appartenant à root (le super- utilisateur local) avec
substitution d’utilisateur.
C’est pourquoi la commande mount offre plusieurs
paramètres :
Lecture seulement
Active/désactive la substitution d’utilisateur ou de groupe
(fstab): /dev/fd0 /mnt/floppy2 ext2
noauto,user,exec,suid 0 0
Désactive les périphériques
29/36
L’utilisation d’un chemin de recherche de fichiers peut introduire

une attaque de mascarade.
Ex :
PATH=.:/usr/bin:/bin:/usr/local/bin:/usr/games
La première entrée correspond au répertoire courant.
Lorsqu’une commande est tapée dans le shell, chaque
répertoire est parcouru pour trouver le fichier exécutable de la
commande.
Si la commande su se trouvant dans /bin, alors en mettant
une version pirate de su dans /usr/bin, c’est elle qui sera
exécutée. Un autre endroit serait le répertoire courant.
Une défense consiste à placer au début du chemin des
répertoires auxquels on fait confiance (surtout pas le
répertoire courant !)
Une autre défense est de se définir des alias du genre :
alias su ’/bin/su’
30/36
Journaux d’audit
Journaux d’audit et détection
Comme les mécanismes de protection ne couvrent pas toujours

tout (surtout dans Unix), il est bon d’avoir aussi à notre
disposition des mécanismes de détection :
Journaux d’audit pour analyse ultérieure
Détection d’intrusion par l’analyse des comportements
suspects
Riposte automatisée à l’intrusion
31/36
Journaux d’audit
Il faut protéger le journal d’audit des modifications :

L’accès en modification requiert des privilèges très élevés.
Envoyer périodiquement le journal d’audit sur une autre
machine l’utilisateur où root n’a pas d’accès privilégié.
Envoyer périodiquement le journal d’audit sur une autre
machine qui a été débarrassé des outils superflus.
Envoyer le journal d’audit à une imprimante sécurisée .
32/36
Journaux d’audit
L’administrateur doit décider du niveau de détail du journal

d’audit :
Trop de détails rend les actions suspectes difciles à détecter.
Pas assez de détails peut nous faire rater une attaque
importante.
De plus, il faut éviter de trop surveiller les individus (état
police) !
33/36
Journaux d’audit
Voici quelques fichiers de journaux importants :

/var/log/lastlog Enregistre les derniers ”login”
/var/run/utmp Information pour la commande who
/var/log/wtmp Enregistre les ”logins” et ”logouts”
(commande last)
Les noms précis de ces fichiers peuvent changer d’une version
d’Unix à une autre.
34/36
Journaux d’audit
Il faut décider ce qui se passe lorsque le journal d’audit grossit :

Effacement des entrées les plus anciennes (liste circulaire)
Laisser grossir sans contrôle
Suspendre le système jusqu’à l’action d’un administrateur
L’analyse d’un journal d’audit est longue et ennuyeuse.
Des logiciels spécialisés : ippl, iplog , iptraf , Snort,
TCPDump
L’utilisation d’un système expert (IA) peut aider.
L’identité d’un utilisateur fait partie des informations journalisées :
Cependant, s’il y a eu substitution d’identité, quelle identité
devrions-nous utiliser ?
Les version plus sécuritaires de Unix conservent l’UID original
dans le journal d’audit, plutôt que l’UID de substitution
35/36
Journaux d’audit
Conclusion
Sécurité basée sur permissions/droit d’accès

Utilisateurs/groupes, invocation contrôlée
Détection des attaques
36/36

Sécurité Sous Unix

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Sécurité Sous Unix

Transféré par

Droits d'auteur :

Formats disponibles

Sécurité sous Unix

Introduction : sécurité des systèmes d’exploitation Sécurité sous Unix

1 Introduction : sécurité des systèmes d’exploitation

2 Sécurité sous Unix

1 Introduction : sécurité des systèmes d’exploitation

2 Sécurité sous Unix

Sécurité du système d’exploitation

La base de la sécurité de la plupart des systèmes d’exploitation

L’information sur les utilisateurs (sujets) sont contenus dans

La base de la sécurité de la plupart des systèmes d’exploitation

Les permissions sur les ressources (objets) sont définies par

La sécurité d’un SE s’appuie autant sur la prévention d’actions non

Même si un adversaire astucieux brise nos défenses, il faut

Les meilleurs mesures de protection ne servent à rien si elles sont

La plupart des SE ont des options par défaut à l’installation

En résumé, un cadre sécuritaire pour l’implantation d’un système

un mécanisme de ”login” dans un compte d’utilisateur

1 Introduction : sécurité des systèmes d’exploitation

2 Sécurité sous Unix

Un compte d’utilisateur est identifié par un nom d’utilisateur et

le format standard du contenu du fichier /etc/passwd est le

Un utilisateur est désigné par un nom d’utilisateur, mais

Le super-utilisateur peut à peu près tout faire :

Tous ces pouvoirs rend ce compte très attrayant pour un adversaire

Toutes les précautions doivent être prises pour empêcher

Un utilisateur appartient à un ou plusieurs groupes.

cartoons:*: 999: bugs, dafy, elmer, sam

Par défaut, un programme s’exécute avec les privilèges de

Un programme ayant l’attribut SGID (substitution de groupe)

Il faudra valider que le programme utilisant la substitution

Exemple de structure de fichiers :

drwxr-x--- 1 martinr chacours 1024 Jan 24 12: 00 .

La première lettre indique le type de fchier -= fchier, d=

Noter les 2 premiers fchiers . et ..

Que peut- on déduire au niveau des droits d’accès ?

drwxr-x--- 1 martinr chacours 1024 Jan 24 12: 00 .

Gestion des droits d’accès

Gestion des droits d’accès

C’est par cette commande qu’on peut :

Gestion des droits d’accès

La commande chown permet de modifier le propriétaire d’un

Ces commandes, combinées avec les attributs de substitution

Gestion des droits d’accès

Droits par défaut

Par défaut, les nouveaux fichiers reçoivent une permission Il est

Gestion des droits d’accès

Utiliser l’invocation contrôlée pour gérer l’accès à une

Créer un nouveau UID qui possède la ressource et tous les

Gestion des droits d’accès

Un adversaire peut éviter certaines mesures de protection en

Gestion des droits d’accès

Le montage de disques par la commande mount est susceptible à

Gestion des droits d’accès

L’utilisation d’un chemin de recherche de fichiers peut introduire

Journaux d’audit et détection

Comme les mécanismes de protection ne couvrent pas toujours

Il faut protéger le journal d’audit des modifications :

L’administrateur doit décider du niveau de détail du journal

Voici quelques fichiers de journaux importants :

Il faut décider ce qui se passe lorsque le journal d’audit grossit :

Sécurité basée sur permissions/droit d’accès

Vous aimerez peut-être aussi