Retrouvez cet article dans : Linux Magazine Hors série 17
SELinux ou Security Enhanced Linux est une solution de sécurité développée par la NSA qui s'intègre au noyau linux.
Généralités
SELinux est une solution de sécurité offrant un blindage du noyau Linux, en lui apportant des fonctionnalités de protection poussées supplémentaires comme le Mandatory Access Control, etc., que nous allons détailler dans l'article (cf Architecture). Ce projet correspond à une initiative américaine et a été lancé par la NSA : National Security Agency. Cette agence de renseignement qui compte près de 40000 personnes est assez connue du grand public depuis les révélations concernant le projet Echelon, réseau planétaire de surveillance et d'interception de communications [Assemblée2000]. La NSA s'appuya initialement sur des piliers industriels comme MITRE, Secure Computing Corporation et NAI, avec une participation du tissu universitaire américain. La première mouture publique de SELinux a été donnée à la communauté du logiciel libre (licence GPL) vers la fin 2000 par le Information Assurance Research Office qui pilote le projet. Cette entité de la NSA demeure responsable de la recherche et du développement de solutions de sécurité dans le domaine des technologies de l'information, pour des infrastructures sensibles avec une vocation gouvernementale et industrielle (projet à prendre au sérieux, donc). Cette première version de SELinux était fournie sous forme de patch du noyau Linux et lança une impulsion significative (supplémentaire) concernant la sécurité bas niveau du fameux kernel. La communauté Linux (et Linus Torvalds en particulier) décida alors de créer un framework de sécurité dans le noyau qui donna plus tard naissance à Linux Security Module (voir l'article dédié dans ce hors série). Avec NAI, la NSA changea alors son implémentation de SELinux pour passer d'un patch à un simple module noyau comme nous le verrons plus loin dans l'article. En effet, nous commencerons par introduire l'architecture globale de SELinux (Flask...) et son intégration au noyau existant (LSM...), pour ensuite détailler son fonctionnement interne et ce qui façonne ses atouts (TE, RBAC) avant d'aborder rapidement des aspects pratiques comme l'installation ou la configuration. Nous conclurons enfin sur ce que cela apporte concrètement en sécurité, les limites, et terminerons sur le potentiel futur de ce projet.
Architecture
SELinux a été conçu sur le modèle de l'architecture Flask [Spencer99]. Au début, l'implémentation avait été faite sous forme de patch pour le noyau Linux. Par la suite, avec la création de l'architecture Linux Security Module (LSM), SELinux a progressivement évolué vers un module de sécurité utilisant les nouvelles fonctions du noyau. Remarquons au passage que l'implémentation de SELinux sous forme de module a donné lieu à une énorme contribution au projet LSM [Smalley01].Mandatory Access Control
La protection apportée par SELinux est fondée sur le principe de Mandatory Access Control (MAC), en français : contrôle d'accès obligatoire. Contrairement au contrôle d'accès typique d'un système Unix, Discretionary Access Control (DAC), qui laisse le problème du contrôle d'accès à une ressource à la discrétion de son propriétaire, le but de MAC est de vérifier la légitimité de tous les accès par des sujets (processus) à des objets (fichiers, sockets...), et ceci à partir d'une politique de sécurité définie au préalable (cf [HSLM16/LSM]. Cependant, le MAC, que l'on retrouve dans de nombreuses solutions de sécurité, n'est pas l'apport principal de SELinux. En fait, ce qui caractérise vraiment la réalisation de la NSA est l'architecture Flask, déployée dans le noyau pour implémenter le MAC. Nous allons maintenant voir plus en détail l'architecture Flask.Flask
Flask est un modèle très flexible autorisant l'implémentation de différents modèles de sécurité. Il repose sur une séparation complète entre le code de décision et le code d'application de la politique de sécurité. Par conséquent, SELinux constitue une sorte de gouvernement où le pouvoir législatif et le pouvoir exécutif sont détenus par des entités distinctes. La partie décisionnelle de l'architecture (policy decision-making code) de SELinux est contenue dans un composant particulier du noyau appelé le security server (en français, référentiel de sécurité). Cette partie constitue le "pouvoir législatif" dans SELinux. Elle établit les lois à partir de la politique de sécurité à appliquer sur le système. La partie d'application (policy enforcement code) de la politique de sécurité est directement intégrée dans les composants du noyau gérant les processus, les systèmes de fichiers, les IPC et le réseau. C'est le "pouvoir exécutif" de SELinux, responsable de l'application des lois dans le système. Enfin, SELinux comporte également un système de cache, pour un accès rapide aux décisions d'accès qui ont déjà été calculées par le référentiel de sécurité. Il s'agit de l'Access Vector Cache (AVC). Pour que ce modèle soit indépendant de la politique de sécurité à appliquer, les interactions entre sujets et objets sont modélisées. Chaque entité du système reçoit unModèles de sécurité
SELinux offre la possibilité d'utiliser différents modèles de sécurité. Suivant les modèles utilisés, les possibilités seront différentes, mais les principes de fonctionnement restent les mêmes, comme décrits dans la partie précédente. La politique de sécurité que l'on va pouvoir définir à partir de ces différents modèles est destinée à piloter le mécanisme de Mandatory Access Control. Pour plus d'informations, la lecture de [Amoroso94] est une bonne base. Actuellement, le référentiel de sécurité implémenté dans SELinux est une combinaison de Type Enforcement et de Role-Based Access Control. Une implémentation de Multi-Level Security est en cours, ainsi qu'une implémentation de la norme CIPSO/FIPS188 pour l'application de labels au trafic réseau. Comme expliqué dans la partie précédente, afin de pouvoir modéliser les interactions entre sujets et objets de façon efficace, SELinux attribue des labels (contextes de sécurité) aux entités du système. Il va s'agir d'une combinaison des identifiants déclarés par les différents modèles de sécurité. Par exemple :Type Enforcement
Le modèle de sécurité Type Enforcement (TE) implémenté dans SELinux est dérivé du modèle Domain and Type Enforcement. Dans DTE, tous les objets et processus du système reçoivent des attributs de sécurité. Ils sont appelésattribute domain; attribute file_type; attribute sysadmfile; type syslogd_t, domain; type resolv_conf_t, file_type, sysadmfile;Après le mot clé type, le premier identifiant est le type déclaré, puis les identifiants suivants sont des attributs associés au type (on peut déclarer autant d'
type syslogd_t, domain;
type syslogd_exec_t, file_type, sysadmfile, exec_type;
domain_auto_trans(initrc_t, syslogd_exec_t, syslogd_t)
allow syslogd_t self:process { fork signal };
Voici quelques lignes tirées de la configuration de Role-Based Access Control
Le modèle original de Role-Based Access Control (RBAC) assigne des rôles aux utilisateurs, et associe des permissions à ces rôles. Le modèle de SELinux associe à chaque utilisateur un ensemble de rôles, et associe à chaque rôle un ensemble de domaines TE. SELinux combine ainsi les facilités de gestion du RBAC, et la finesse des contrôles d’accès du modèle TE. Par exemple, la règle suivante indique que le rôlesyslogd_t. role system_r types syslogd_t;Les rôles sont inclus dans les contextes de sécurité associés aux sujets et objets du système. Pour les objets, il existe un rôle générique
constrain process transition ( r1 == r2 or t1 == privrole ); allow system_r sysadm_r; SELinux User IdentityLes UID traditionnelles de Linux ne conviennent pas pour SELinux. En effet, un même utilisateur peut utiliser plusieurs UID au cours de son activité sur le système, par exemple lorsqu’il utilise des programmes nécessitant des privilèges. Un programme lancé par root peut prendre n’importe quelle UID via les fonctions set*uid. SELinux introduit donc un attribut reflétant l’identité de l’utilisateur dans le contexte de sécurité, complètement indépendant de l’UID. Il est ainsi possible pour SELinux d’effectuer des contrôles sur l’identité de l’utilisateur sans LMHS17.qxd 29/09/03 14:47 Page 40 Novembre/Decembre 2003 41 perturber le système de contrôle d’accès discret (DAC) de Linux. Dans la politique de sécurité standard de SELinux, seuls certains domaines ont la possibilité de modifier l’identité de l’utilisateur. Par exemple, les programmes login et sshd ont été modifiés afin d’utiliser les fonctions des bibliothèques fournies avec SELinux. Ainsi, les identités appropriées sont attribuées aux utilisateurs qui se connectent sur le système. En outre, un utilisateur donné conservera en permanence son identité SELinux, même s’il utilise une commande telle que su, on obtient ainsi une meilleure traçabilité.
user root roles { user_r sysadm_r };
user moutane roles { user_r sysadm_r };
user lolo roles { user_r };
constrain process transition ( u1 == u2 or t1 == privuser );
Voici quelques déclarations d'utilisateurs avec les rôles qu'ils peuvent prendre. La dernière ligne se trouve dans le fichier Multi-Level Security
Le modèle de sécurité MLS est parmi les plus proches du modèle Bell-LaPadula [Bell73]. Il attribue des niveaux de confidentialité aux différents objets et utilisateurs du système. Assez proche de la notion du besoin d'en connaître du milieu militaire, ce modèle était par exemple implémenté dans certains systèmes Unix, notamment des systèmes d'exploitation Cray. L'implémentation SELinux n'est pas encore terminée, mais il est déjà possible d'associer des niveaux de confidentialité à toutes les entités du système. Ensuite, le contrôle d'accès est simple : on n'a accès en lecture à un objet d'un certain niveau de classification que si l'on possède soi-même un niveau supérieur ou égal; et l'on n'a le droit de modifier un objet que si l'on possède un niveau égal.sensitivity unclassified alias u;
sensitivity confidential alias c;
sensitivity secret alias s;
sensitivity top_secret alias ts;
dominance { u c s ts }
L'exemple donné ici est la déclaration des différents niveaux de classification utilisés dans MLS, avec la hiérarchie associée.
Labeled Networking Support
SELinux comporte également un modèle de trafic réseau labellisé. Il repose sur une nouvelle option de l'en-tête IP décrite dans CIPSO/FIPS-188. L'objectif est de pouvoir associer les paquets IP à des SID, qui pourront être décodés par le destinataire du trafic. Ce décodage est fait par le protocole Security Context Mapping Protocol (SCMP). Ce modèle peut être mis en place sur un parc de machines où les politiques SELinux sont équivalentes, i.e. les utilisateurs, les types, les rôles et les niveaux MLS sont les mêmes sur chaque machine. Ce parc de machines, aussi appelé "périmètre de sécurité", doit être déclaré dans la configuration de la politique. Les SID sont alors transmis de façon transparente à l'intérieur de ce périmètre. En revanche, ce modèle ne définit aucune protection du trafic. Elle est pourtant nécessaire, et doit être apportée par des moyens annexes, afin de garantir confidentialité, intégrité, imputabilité et protection contre le rejeu.Intégration de SELinux...
L'intégration de SELinux dans une distribution GNU/Linux ne se fait pas seulement au niveau du noyau. Comme mentionné dans la partie sur RBAC, plusieurs démons et utilitaires doivent être modifiés afin de prendre en compte l'environnement SELinux.... dans le noyau
A l'intérieur du répertoire contenant les sources du noyau (souvent... dans les démons et utilitaires
SELinux comporte une bibliothèque,Guide d'installation
Dans cette partie, seules les étapes les plus significatives de l'installation seront détaillées. Le fichier README de l'archive SELinux est un très bon guide. Les chemins cités sont relatifs au dossier d'extraction de l'archive SELinux. Pour commencer, il faut télécharger l'archive contenant les sources de SELinux sur le site de la NSA [SELinux]. Plusieurs options sont possibles ; on choisit ici de télécharger séparément les sources du noyau Linux 2.4.21, le patch lsm-2.4 et l'archive selinux. La première étape importante est l'application des patches du noyau. Le patch lsm-2.4 va insérer les ancres de l'infrastructure Linux Security Module dans les sources du noyau. L'intégration définitive de ces ancres devrait se faire dans le noyau 2.6. Il est ensuite nécessaire d'appliquer un second patch spécifique à SELinux, pour ajouter certaines ancres absentes du patch lsm-2.4, ainsi que les options par défaut de SELinux dans la configuration du noyau. Ce patch devrait disparaître avec le noyau 2.6. Une décision importante lors de la compilation du noyau SELinux est celle qui concerne l'option "NSA SELinux Development Support". Elle permet de faire fonctionner SELinux dans un mode permissive, dans lequel aucune action n'est bloquée par SELinux, mais les actions interdites sont enregistrées. Dans ce mode, il est possible de tester des politiques de sécurité sans que les applications ne soient bloquées à cause d'une erreur. Il est possible de passer en mode enforcing par la commande avc_toggle et vice-versa. Si le noyau est destiné à une machine de développement pour SELinux, il vaut mieux activer cette option. Si le noyau doit être utilisé sur une machine de production, alors il est fortement conseillé de ne pas l'activer. Après la compilation du noyau SELinux, une autre étape importante est la compilation et l'installation de la politique de sécurité. Au préalable, il est souhaitable de modifier le fichierConfiguration et outils
Cette partie va décrire rapidement comment configurer les contextes de sécurité des fichiers et modifier la politique de sécurité, puis quels sont les utilitaires spécifiques à SELinux et leurs intérêts. Comment modifier la politique de sécurité Les fichiers de configuration se trouvent dans le sous-dossierLes outils de configuration
Dans le dossier d'installation, le dossierLes utilitaires classiques
Les utilitaires installés avec SELinux sont de deux sortes : les utilitaires classiques modifiés et les utilitaires spécifiques. De nombreux utilitaires ont été modifiés pour afficher les informations relatives à SELinux. Voici une liste non exhaustive, mais déjà relativement longueÂmoutane@node1:~% /usr/local/selinux/bin/ls —context / drwxr-xr-x root bin system_u:object_r:bin_t bin drwxr-xr-x root root system_u:object_r:boot_t boot drwxr-xr-x root root system_u:object_r:device_t dev drwxr-xr-x root root system_u:object_r:etc_t etc drwxr-xr-x root root system_u:object_r:home_root_t home drwxr-xr-x root root system_u:object_r:lib_t lib drwxr-xr-x root root system_u:object_r:file_t mnt dr-xr-xr-x root root system_u:object_r:proc_t proc drwx--x--- root root system_u:object_r:sysadm_home_dir_t root drwxr-xr-x root bin system_u:object_r:sbin_t sbin drwxrwxrwt root root system_u:object_r:tmp_t tmp drwxr-xr-x root root system_u:object_r:usr_t usr drwxr-xr-x root root system_u:object_r:var_t var moutane@node1:~% /usr/local/selinux/bin/ps ax —context PID SID CONTEXT COMMAND 1 7 system_u:system_r:init_t init 2 1 system_u:system_r:kernel_t [keventd] 3 1 system_u:system_r:kernel_t [ksoftirqd_CPU0] 4 1 system_u:system_r:kernel_t [kswapd] 5 1 system_u:system_r:kernel_t [bdflush] 6 1 system_u:system_r:kernel_t [kupdated] 78 207 system_u:system_r:syslogd_t /usr/sbin/syslogd 83 208 system_u:system_r:klogd_t /usr/sbin/klogd -c 3 -x 85 210 system_u:system_r:inetd_t /usr/sbin/inetd 88 212 system_u:system_r:sshd_t /usr/sbin/sshd 112 217 system_u:system_r:local_login_t login — moutane 113 216 system_u:system_r:getty_t /sbin/agetty 38400 tty1 linux 118 218 moutane:sysadm_r:sysadm_t -zsh 138 218 moutane:sysadm_r:sysadm_t -su 155 221 moutane:sysadm_r:honeyd_t /usr/local/bin/honeyd -f config.default moutane@node1:~% id uid=1000(moutane) gid=1000(moutane) groups=1000(moutane) context=moutane:sysadm_r:sysadm_t sid=218 moutane@node1:~% su - Password: root@node1:~# id uid=0(root) gid=0(root) groups=0(root),10(wheel) context=moutane:sysadm_r:sysadm_t sid=218La commande ls est lancée ici avec le modificateur context. En plus des informations classiques telles que les permissions, UID et GID, on obtient les contextes de sécurité des objets. Par exemple, le dossier
Protection apportée
Sans détailler tous les aspects techniques présentant ce qu'apporte SELinux en sécurité, nous allons succinctement montrer en quoi une machine avec un tel système d'exploitation pourra résister face à la plupart des agressions connues. Voici une question qui revient souvent quand on compare SELinux et d'autres solutions comme Grsecurity utilisant PAX : est-ce que SELinux bloque les buffers overflows et gêne les pirates avec des aléas dans les adresses de fonctions référencées dans des bibliothèques dynamiques, etc. ? La réponse est négative. En effet, si SELinux ne bloque ou ne gère certaines possibilités utilisées par les agresseurs, il faut comprendre que le concept est différent : une fois l'attaque lancée vers un programme contenant des failles, elle sera limitée à ce que le programme est capable de faire. On a donc une assurance du principe dit de containment permettant de contenir un intrus ayant réussi à percer certaines barrières qui ne dépendent pas de SELinux directement. L'exemple donné dans [SYSADMIN03] rappelle ainsi que si un service Apache qui tournerait en root se faisait pirater sur un serveur SELinux (via buffer overflow, etc.), alors ce dernier ne pourrait modifier par exemple la configuration du serveur Bind local à ce serveur. En effet, le Security Server de SELinux, utilisant les politiques de sécurité qui ont été chargées dans le noyau, interdira au processus Apache agressé d'agir autrement que ce qu'on lui a imposé. Usuellement, lorsqu'un pirate rentre sur une machine à distance, il essaie de lancer un shell pour pouvoir visiter à sa guise sa nouvelle conquête. Avec SELinux, l'appel Ã# [attention on rappelle que ceci est montré pour illustration] # Le binaire honeyd /usr/local/bin/honeyd system_u:object_r:honeyd_exec_t # Les fichiers de configuration de honeyd /usr/local/share/honeyd system_u:object_r:honeyd_conf_t /usr/local/share/honeyd/nmap.assoc system_u:object_r:honeyd_conf_t /usr/local/share/honeyd/xprobe2.conf system_u:object_r:honeyd_conf_t /usr/local/share/honeyd/nmap.prints system_u:object_r:honeyd_conf_t # Le fichier de paramétrage de honeyd que nous utilisions # sachant quÂ’il faut développer le sien /usr/local/share/honeyd/config.sample system_u:object_r:honeyd_conf_t # Les scripts lancés par honeyd /usr/local/share/honeyd/scripts(/.*)? system_u:object_r:honeyd_script_exec_t # Les logs des scripts test.sh et web.sh vont dans /tmp/log /tmp/log system_u:object_r:honeyd_script_log_t # ...Une fois ces ressources labellisées, il faut déterminer l'ensemble des privilèges et possibilités de
 # [attention on rappelle que ceci est montré pour illustration]
# Declarons honeyd comme daemon réseau
daemon_domain(honeyd)
can_network(honeyd_t)
# Type declarations pour honeyd
type honeyd_conf_t, file_type, sysadmfile;
type honeyd_script_exec_t, file_type, sysadmfile, exec_type;
type honeyd_script_log_t, file_type, sysadmfile;
type honeyd_script_t, domain, privlog;
# Honeyd peut être exécuté par init ou l’admin
role system_r types honeyd_t;
role sysadm_r types honeyd_t;
# Quand sysadm lance honeyd, il passe dans le domaine honeyd_t
domain_auto_trans(sysadm_t, honeyd_exec_t, honeyd_t)
# Autorisation à honeyd de lire les fichiers de configuration
# Meme si ces fichiers étaient en écriture (rw-), honeyd ne pourrait
# les modifier, à cause du MAC assuré grâce à ces lignes de politiques
allow honeyd_t honeyd_conf_t:dir { search };
allow honeyd_t honeyd_conf_t:file { getattr read };
# /dev/urandom utilisé par honeyd pour générer des nombres aléatoires
allow honeyd_t random_device_t:chr_file { read };
# Honeyd a besoin du réseau
# La capability net_raw est nécessaire (sniffer réseau à base de libpcap)
allow honeyd_t honeyd_t:capability { net_raw };
# reste du réseau :
allow honeyd_t honeyd_t:packet_socket { bind create getopt ioctl read
setopt write };
allow honeyd_t honeyd_t:rawip_socket { sendto write create getopt setopt };
# ...
Si Limites
Complexité d'administration
En regardant en détail le fonctionnement de SELinux, vous aurez sûrement compris qu'une des premières difficultés rencontrées concerne l'exploitation de cette solution. En effet, si la mise en place est envisageable sur une machine jouant un rôle particulier (serveur Web et DNS, etc.), le déploiement de SELinux sur un réseau de plusieurs machines peut demander un travail important (par exemple sur un parc de postes de travail, etc.). Notons par exemple qu'il n'existe pas encore de moyens pour gérer le déploiement et la configuration des règles de sécurité à distance. Cela ne serait de toutes façons pas suffisant, car la complexité des règles et fichiers à gérer pour SELinux est telle qu'une compréhension de ce qui est installé sur tout un parc informatique semble illusoire. Certains outils encore pauvres ou en développement par différents sites (console Webmin, etc.) permettront peut-être de pallier cela, à moins que l'on ne voit plutôt apparaître des solutions clef en main (distributions blindées basées sur SELinux) qui nécessiteraient peu de maintenance et de paramétrage de la part des administrateurs. D'autres outils manquent encore, comme l'intégration du backup des contextes de sécurité des fichiers (labels). Notons de plus qu'aucun retour d'expérience véritable et reconnu n'existe à ce jour sur la mise en production de SELinux, la NSA elle-même se gardant un droit de réserve compréhensible sur la question (Never Say Anything). Enfin, dans le cadre de l'ajout d'une application qui n'aurait pas été prévue initialement, donc sans politique de sécurité, l'écriture de cette dernière peut s'avérer très difficile si l'on veut être certain d'appliquer le principe de moindre privilège. Il semble en effet nécessaire de bien connaître à l'avance le fonctionnement de l'application à intégrer dans SELinux. Pour générer des politiques de sécurité, on peut utiliser l'outilRobustesse
A priori, à ce jour, aucune faille majeure sur le projet SELinux n'a été annoncée publiquement. Par contre, s'il peut transformer le noyau Linux avantageusement, il ne faut pas oublier que la sécurité qu'il apporte sera basée notamment sur la qualité des politiques de sécurité (et leur maintenance, car les applications évoluent rapidement, surtout dans le logiciel libre, et les politiques de sécurité doivent donc suivre). Aussi, nous avons pu constater que certaines proposées par des contributeurs SELinux ne sont pas peaufinées pour limiter fortement un pirate (les démons peuvent souvent lire toutGentoo SELinux, root en libre service, mot de passe : “gentoo” $ ssh -a -x root@selinux.dev.gentoo.org Debian SELinux, root en libre service, mot de passe : “azerty” $ ssh -a -x root@cose.coker.com.auPendant le FOSDEM 2003 à Bruxelles, une machine Debian SE Linux était installée de la même manière pour tous les attaquants potentiels désirant tester la fiabilité de SE Linux (concours monté sur place et non annoncé sur le site du FOSDEM) : personne ne perça la machine.
Conclusion et perspectives
Si nous devions coller un seul adjectif à SELinux, nous choisirions sans hésiter le suivant : ambitieux. En effet, les possibilités quant à la sécurité sont très complètes et la NSA a ainsi offert au logiciel libre un bel exemple et élan en termes de recherche et de développement sur la façon de construire un système d'exploitation robuste, fiable et stable. La contre-partie de ce caractère ambitieux réside dans la difficulté de définir des politiques de sécurité fines pour l'ensemble des applications utilisées par un système d'exploitation standard. Cela nécessite un investissement important pour tenir à la fois compte des spécificités des applications, de la grammaire de SELinux et des contextes de déploiement. Par ailleurs, il faut garder à l'esprit que ce genre de solution ne couvre que l'aspect "modélisation" du problème de containment, et à ce titre, d'autres solutions plus simples à déployer, comme [GrSecurity], intégrant notamment des protections contre l'abus des failles logicielles (PaX), semblent complémentaires et méritent d'être prises en compte. Quel futur attend donc ce projet libre très avancé techniquement ? On voit déjà poindre à l'horizon des solutions de sécurité utilisant SELinux (plateformes robustes dédiées à certaines fonctions, etc.). Par ailleurs, certaines parties de SELinux sont encore en développement, comme selopt qui pourrait permettre de transporter les SID au travers d'un réseau sur un environnement homogène composé de SE Linux (un parc informatique, un cluster de calcul...). Le site de SELinux sur [SourceForge] représente une excellente source d'information. Avec la NSA, force de renseignement américaine colossale derrière un tel projet, ainsi que l'avènement des LSM et du noyau 2.6, gageons que cette solution fera parler d'elle, à moins que des restrictions politiques ne s'y opposent (certains mouvements de pensée aux USA ont annoncé leur étonnement de voir qu'une solution de sécurité était développée grâce aux impôts américains et distribuée gratuitement (sous licence GPL) à tout le monde, y compris leurs "ennemis"...). Références- [SELinux] Security-Enhanced Linux. http://www.nsa.gov/selinux/
- [Assemblée2000] Rapport d'information numéro 2623 de l'Assemblée Nationale française du 11 octobre 2000 intitulé "Les systèmes de surveillance et d'interception électroniques pouvant mettre en cause la sécurité nationale". Voir le chapitre I-A nommé "Une organisation vraisemblablement détournée de sa finalité militaire initiale".
- [Spencer99] Ray Spencer, Stephen Smalley, Peter Loscocco, Mike Hibler, David Andersen and Jay Lepreau. The Flask Security Architecture: System Support for Diverse Security Policies. In Proceedings of the 8th USENIX Security Symposium, 1999.
- [Smalley01] Stephen Smalley, Chris Vance and Wayne Salamon. Implementing SELinux as a Linux Security Module. 2001. http://www.nsa.gov/selinux/module-abs.html
- [Bell73] D. E. Bell and L. J. LaPadula. Secure Computer Systems: Mathematical Foundations and Model. Technical Report, The MITRE Corp., Number M74-244, May 1973.
- [Amoroso94] Edward Amoroso. Fundamentals of Computer Security Technology. 1994. ISBN 0-13-108929-3.
- [PolicyConf] Stephen Smalley. Configuring the SELinux Policy. Last revised: January 2003. http://www.nsa.gov/selinux/policy2-abs.html
- [SYSADMIN03] Kerry Thomson. SELinux. In SysAdmin Magazine, March 2003, Volume 12, Number 3
- [MISC8] Arnaud Guignard, Laurent Oudot, V. G. Honeyd. In MISC Magazine n°8, Juillet-Août 2003.
- [RSTACK] Configuration de SELinux pour honeyd (pour test) http://www.rstack.org
- [FAQ]The UnOfficial SELinux FAQ. http://www.crypt.gen.nz/selinux/faq.html
- [Coker]Security Enhanced Linux information. http://www.coker.com.au/selinux/
- [SourceForge] SELinux Distribution Integration News. http://selinux.sourceforge.net/
- [HOWTO]Getting Started with SE Linux HOWTO. http://sourceforge.net/docman/display_doc.php?docid=15285&group_id=21266
- [RedHat]Red Hat on Security: SELinux. http://www.redhat.com/solutions/security/SELinux.html
- [GrSecurity] http://www.grsecurity.org/
Retrouvez cet article dans : Linux Magazine Hors série 17
Donnez votre avis
Vous devez avoir ouvert une session pour écrire un commentaire.