Étude de NSA Security Enhanced Linux : SELinux

Université Henri Poincaré - Nancy I
      Isial: Institut Supérieur d’Informatique de d’Automatique de Lorraine

           Diplôme d’Études Supérieures Spécialisées d’Infomatique
                          Second projet de l’option

               Responsable Tronc Commun : Nacer B OUDJLIDA
Responsable option Ingénierie des Réseaux et des Systèmes : Bernard M ANGEOL




     Étude de NSA     Security Enhanced Linux : SELinux
            Mathieu B AEUMLER, David H OEUNG et Laurent VALLAR,




                            Nancy, le 29 mars 2004
TABLE DES MATIÈRES                                                                                                                 1


Table des matières
1 introduction                                                                                                                     2
  1.1 presentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                               2
  1.2 historique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                             3

2 Linux Security Modules                                                                                                           4
  2.1 Contrôle d’accès . . . . . . . . . . . . . . . .                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
      2.1.1 Modèle de sécurité . . . . . . . . . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
      2.1.2 Politiques et mécanismes . . . . . . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    4
  2.2 Architecture des LSM . . . . . . . . . . . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
      2.2.1 Points de contrôle . . . . . . . . . . . .                .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    7
      2.2.2 Champs de sécurité . . . . . . . . . .                    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .    9
      2.2.3 Communication avec l’espace utilisateur                   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   12
      2.2.4 Tests de consistance . . . . . . . . . .                  .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   13
      2.2.5 Enregistrement et empilage des LSM .                      .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   16

3 Architecture de SELinux                                                                                                         20
  3.1 Mandatory Acces Control . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   20
  3.2 Le modèle Flask . . . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   20
  3.3 Modèles de sécurité . . . . . . . .     .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   21
      3.3.1 Type Enforcement . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   21
      3.3.2 Role-Based Access Control         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   22
      3.3.3 Multi-Level Security . . . . .    .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23
      3.3.4 Labeled Networking Support        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   23

4 Intégration de SELinux                                                                                                          24
  4.1 dans le noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .                                             24
  4.2 dans les démons et utilitaires . . . . . . . . . . . . . . . . . . . . . . . .                                              24

5 Etude de la mise en œuvre sur Mandrake                                                                                          25
  5.1 Contexte . . . . . . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
  5.2 Objectifs . . . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
  5.3 Contraintes . . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   25
  5.4 Réalisation . . . . . . . . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   26
  5.5 Problèmes rencontrés . . . . . . . . .          .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   27
      5.5.1 sur le noyau . . . . . . . . . . .        .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   27
      5.5.2 sur la distribution . . . . . . . .       .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   28
      5.5.3 sur le contexte . . . . . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   29
      5.5.4 complexité de la mise œuvre . .           .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   30
  5.6 Solutions préconisées . . . . . . . . .         .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   .   30

6 Conclusion                                                                                                                      32

Table des figures                                                                                                                 33

Bibliographie                                                                                                                     34
1   INTRODUCTION                                                                          2


1     Introduction
1.1   Présentation
   SELinux (Security Enhanced Linux) 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, en autre, le MAC (Mandatory Access Control), que nous allons détailler plus loin.

   Ce projet est une initiative américaine et a été lancé par la NSA (National Security
Agency ), assez connue du grand public depuis les révélations concernant le projet Eche-
lon, réseau planétaire de surveillance et d’interception de communications.

    La première mouture publique de SELinux a été donnée à la communauté du Logiciel
Libre (sous licence GPL) vers la fin 2000 par l’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...

    Nous commencerons par introduire l’architecture globale de SELinux (Flask...) et son
intégration au noyau existant via les LSM (Linux Security Modules), pour ensuite détailler
son fonctionnement interne et ce qui façonne ses atouts (principalement TE et RBAC
qui seront présentés plus loin) avant de détailler l’ensemble des problèmes rencontrés
dans le cadre restreint de l’ installation d’une passerelle d’accès sécurisée sous distribu-
tion Mandrake pour le Loria (Laboratoire lOrrain de Recherche en Informatique et ses
Applications).

    Mais, avant de débuter la partie purement technique, nous allons faire un bref rappel
de l’historique de l’entrée de SELinux dans l’univers de la communauté Linux.
1    INTRODUCTION                                                                              3


1.2     Historique
   Lors du Kernel Summit de San Jose, en mars 2001, Peter Loscocco présenta Security
Enhanced Linux (SELinux), un patch pour le noyau Linux implémentant une architecture
de contrôle d’accès, tous deux développés par la NSA.

    SELinux n’était pas le seul correctif de la sorte, D’autres projets comme RSBAC, Me-
dusa DS9, LIDS, SubDomain, DTE ou encore LoMAC [rsbac, medusa, lids, subdomain,
dte, lomac] implémentent d’autres contrôles d’accès ou d’autres charpentes de contrôle
d’accès.

    Linus Torvalds, conscient de la nécessité de permettre d’autres types de contrôles
d’accès en standard, autres que ceux déjà présents1 , et plutôt que de privilégier un type
de contrôle d’accès sur tous les autres, décida alors qu’il serait prêt à intégrer dans la
distribution standard du noyau 2.6 une charpente commune laissant à chacun le choix de
sa méthode de contrôle d’accès.

    Ainsi naquit le projet Linux Security Modules (LSM). La charpente prit la forme d’un
ensemble de points de contrôle (hooks ou ancres) dans le noyau Linux, afin de brancher
les différents type de contrôles d’accès. On y trouve actuellement une implémentation de
SELinux , LIDS, DTE, et même les capabilities ont été sorties du noyau pour s’appuyer
sur le projet LSM.

    Il est à noter que le mot module dans les LSM ne signifie pas que le contrôle d’accès
doit être implémenté sous forme de module noyau (LKM), mais que la charpente est assez
bien faite pour que tout code de contrôle d’accès l’utilisant soit modulaire. On peut ainsi le
compiler sous forme de module si on le désire, mais rien ne nous y oblige.




    1 C’est
         à dire le Discretionary Access Control : DAC, les droits UNIX que tout le monde connaît,
avec en plus les capabilities
2   LINUX SECURITY MODULES                                                                 4


2       Linux Security Modules
2.1     Contrôle d’accès
   Lorsque l’on souhaite sécuriser un système, il est indispensable de mettre en place
un mécanisme de contrôle d’accès. Ce mécanisme doit décider si une requête doit être
acceptée ou si elle doit être rejetée...


2.1.1    Modèle de sécurité
  Pour pouvoir prendre les décisions de contrôle d’accès, il faut déterminer QUI peut
ACCÉDER à QUOI.

    – Qui : Un sujet est une entité agissant sur le système
      (exemple : un processus agissant pour le compte d’un utilisateur).

    – Quoi : Un objet est une entité passive du système (exemple : un fichier).
      On peut noter que dans un système, un élément peut-être à la fois sujet et objet, par
      exemple l’utilisateur qui appelle su est un sujet, mais l’identité est un objet.

    – Contrôle d’accès : Le contrôle d’accès est effectué à partir des privilèges, per-
      missions, ou droits de l’utilisateur (exemple : Sous unix les droits sont Read, Write,
      eXecute).

    – Authentification : L’authentfication est de garantir l’identité du sujet (mot de passe,
      smartcard, biométrie). Elle permet ensuite de confronter la requête aux permissions.

    – Audit : L’audit est le mécanisme de supervision de l’ensemble du processus de
      contrôle d’accès. Les événements sont enregistrés. Cela permet de détecter les
      tentatives de violations (offline : après les faits ; ou en temps réel)

    Les sujets détiennent des privilèges sur des objets suivant une politique de contrôle
d’accès mise en œuvre par le moniteur de référence..


2.1.2    Politiques et mécanismes
   Le contrôle d’accès détermine les autorisations et les restrictions, en correspondance
avec une politique de sécurité.

    Le contrôle d’accès est un problème délicat, en particuliers lorsqu’on compare plu-
sieurs sujets. Il existe des rôles différents (utilisateurs normaux, super-utilisateur), des
groupes (étudiants, professeurs). Il peut également y avoir un besoin de déléguer ses
droits.
    Pour résoudre les problèmes de contrôles d’accès plusieurs politiques de sécurité
(DAC, MAC, RBAC), mécanismes (matrice d’accès : ACL, capabilities) ont été mis en
œuvre.
2   LINUX SECURITY MODULES                                                                      5




                           F IG . 1 – Modèle général de sécurité



Discretionary Access Control
      C’est la politique la plus simple. Son nom vient du fait que la discrétion est laissée à
l’utilisateur. Par exemple les droits UNIX. Les droits sont lecture, écriture et exécution. L’uti-
lisateur peut changer les droits sur les objets qu’il possède. Ce type de politique comporte
d’importants défauts :

    – La politique globale de sécurité peut être compromise par un seul utilisateur s’il com-
      met une erreur

    – le flux d’information n’est pas du tout contrôlable : un utilisateur capable de lire des
      données peut les transmettre à un utilisateur non autorisé.



Matrice d’accès
    C’est le mécanisme de contrôle d’accès le plus complet. Il faut identifier les relations
entre les sujets et les objets. Les sujets sont les lignes, et les objets sont les colonnes de
la matrice. Une telle matrice est énorme et creuse, donc peu pratique. Cette matrice est
généralement représentée sous forme de liste.
2   LINUX SECURITY MODULES                                                                 6


Access Control List
   Cette liste représente l’ensemble des colonnes de la matrice de contrôle d’accès. Pour
chaque objet, on associe les utilisateurs avec les opérations auxquels ils peuvent effectuer.


Capability List
   Cette liste représente les lignes de la matrice de contrôle d’accès. Pour chaque sujet,
on associe les objets auxquels il peut accéder, avec les opérations autorisées.


Role-Based Acces Control
    Ce mécanisme introduit ici la notion de classe d’équivalence, avec la matrice de contrôle
d’accès. Une classe (groupe ou rôle) regroupe plusieurs sujets. Ces classes sont utiles
lorsque les sujets changent fréquemment, ce qui permet d’éviter de recalculer la matrice.

    Le modèle de rôles le plus utilisé est l’RBAC basique. Les sujets n’ont pas directement
de droits. Les rôles ont des droits. Les sujets sont affectés à des rôles. Ce modèle est donc
une indirection entre les sujets et les permissions.




                                 F IG . 2 – RBAC basique


    D’autres modèles proposent des hiérarchies de rôles, et des contraintes sur les rôles.


Mandatory Access Control
    Ce contrôle est basé sur l’utilisation de labels associés aux objets et aux sujets.

    – Le label d’un sujet (clearance, accréditation) indique le niveau de confiance de ce
      sujet.

    – Le label d’un objet spécifie le niveau minimal que doit avoir un sujet pour accéder à
      l’objet en question.



Conclusion
    Il existe de nombreux autres modèles de contrôles d’accès, chacun avec ses objectifs.
Lorsque Linus Torvalds a voulu que la sécurité entre dans le noyau, il ne voulait pas impo-
ser un modèle précis. Ainsi les LSM constituent une architecture, et non pas un modèle.

   On peut remarquer que les LSM ne constituent pas une nouveauté et que d’autres
architectures existaient déjà (GFAC, Flask )
2   LINUX SECURITY MODULES                                                                    7


2.2     Architecture des LSM
    L’architecture des LSM est intégrée dans le noyau. Elle est constituée de points de
contrôle et de champs de sécurité. Les points de contrôle sont situés aux endroits cri-
tiques dans le code du noyau. Des champs ont été ajoutés, et sont destinés à contenir des
informations de sécurité.

    Aucune sécurité n’est ajoutée par le LSM, tout le mécanisme du contrôle d’accès ré-
side donc dans le ou les modules qui seront utilisés.

   Le patch LSM enlève le mécanisme de capabilities du noyau, ajoute l’architecture
nécessaire aux points de contrôles, et ajoute les champs de sécurité. Les capabilities
deviennent alors un module de sécurité, utilisant l’architecture LSM.


2.2.1   Points de contrôle
    Un point de contrôle est simplement un appel à une fonction. Cette fonction va autoriser
ou refuser l’accès demandé. Son adresse est stockée dans une structure pointée par la
variable globale security_ops. Le type de cette variable est security_operations.

struct security_operations
{
  int (*sethostname) (char *hostname);
  int (*setdomainname) (char *domainname);
  int (*reboot) (unsigned int cmd);
  ...
}

     Chaque module de sécurité doit donc fournir une structure de ce type. Un module doit
s’enregistrer pour être chargé par le noyau. Lorsqu’il est chargé, il s’enregistre et fait poin-
ter la variable security_ops vers sa structure référençant ses fonctions de contrôle d’accès.

   Voici un exemple de hook (ancre) pour le reboot : la fonction reboot du module est
consultée pour l’autorisation du rédémarrage du système.

/* kernel/sys.c */

asmlinkage long sys_reboot(int magic1, int magic2, unsigned int cmd, void * arg)
{
        char buffer[256];
        int retval;

          /* We only trust the superuser with rebooting the system. */
          if (!capable(CAP_SYS_BOOT))
                  return -EPERM;

          retval = security_ops->reboot(cmd);
2   LINUX SECURITY MODULES                                                                  8


          if (retval) {
                  return retval;
          }

          ...
   Pour les noyaux 2.5.X/2.6.X , le point de contrôle se présente sous la forme d’un appel
à une fonction inline qui se charge de déréférencer security_ops et d’appeler la fonction
du module de sécurité utilisé.

/* include/linux/security.h */

static inline int security_reboot (unsigned int cmd)
{
        return security_ops->reboot (cmd);
}
    Ce double appel est équivalent à la version des noyaux 2.4.X , car la fonction est inline.
L’avantage est que l’appel est plus propre, pour la consultation d’autorisation du reboot, il
devient :

/* We only trust the superuser with rebooting the system. */
if (!capable(CAP_SYS_BOOT))
       return -EPERM;

retval = security_reboot(cmd);
if (retval) {
       return retval;
}
   Les points de contrôle sont évidemment placés à des endroits stratégiques. Ils sont
systématiquement situés juste après les vérifications standards.

   Dans notre exemple précédent la fonction capable est appelée juste avant la fonction
security_reboot du module de sécurité.

   C’est uniquement après les vérifications préalables (capable()), et en cas de non échec,
que le hook (ancre) du LSM est appelé. Le reboot est effectué uniquement si le hook le
permet.

Conséquences
    – les arguments reçus par les points de contrôle sont déjà en espace noyau et les
      contrôles d’erreur ont déjà été effectués.

    – les tests du LSM sont effectués en dernier. Si un seul des tests précédents échoue,
      les tests du LSM ne seront donc pas pris en compte. Un point de contrôle ne peut
      donc pas modifier une décision antérieure (ni postérieure).
2   LINUX SECURITY MODULES                                                                    9


    – les points de contrôle sont restrictifs : Par défaut l’accès est valide. Leur rôle est
      donc de déterminer les situations où l’accès doit être refusé. Le module par défaut
      ne s’oppose pas à la demande, les accès sont autorisés. Ce module est définit dans
      security/dummy.c (module dummy ).

        Tous ces points de contrôle renvoient 0.

/* security/dummy.c */

static int dummy_reboot (unsigned int cmd)
{
        return 0;
}

2.2.2    Champs de sécurité
Définition des Champs
   Pour mettre en œuvre une politique de sécurité, il nécessaire de conserver des don-
nées, servant à prendre les décisions sur l’accès à l’objet.

   Par exemple, dans le modèle BLP2 (MAC), chaque objet possède un label, son ni-
veau de sécurité. La solution la plus simple, pour ajouter des données, est de prévoir pour
chaque objet du noyau un champ void * destiné à contenir les informations de sécurité.

    Le champ de sécurité est donc un pointeur initialisé à NULL. Les définitions des struc-
tures se trouvent dans les sources du kernel dans le répertoire include/linux/.

    Le tableau suivant montre les champs de sécurité ajoutés aux noyau.

Objet                   Header             Structure                          champs

Programme               binftms.h          struct    linux_binprm             void   *security
Processus               sched.h            struct    task_struct              void   *security
FileSystem              fs.h               struct    super_block              void   *s_security
Fichier                 fs.h               struct    inode                    void   *i_security
-                       fs.h               struct    file                     void   *f_security
Paquet                  skbuff.h           struct    sk_buff                  void   *lsm_security
Net dev                 netdevice.h        struct    net_device               void   *security
IPC                     ipc.h              struct    kern_ipc_perm            void   *security
-                       msg.h              struct    msg_msg                  void   *security

    Les objets fichiers désignent des fichiers, des pipes ou des sockets.
    2 modèle,   élaboré en 1975 : Bell-La Padula (BLP), du nom de ses concepteurs.
2    LINUX SECURITY MODULES                                                                    10


Gestion des Champs
    Il est impératif de gérer ces pointeurs (allocation, initialisation, libération, modification,
etc.). Pour cela des points de contrôle ont donc été mis en place pour les gérer.


Gestion mémoire des Champs
    Pour chaque structure contenant un champs de sécurité, les hooks _alloc_security()
et _free_security() sont définis. Dans le cas d’une réussite, ces fonctions re-
tournent 0. Leur argument est la structure dans laquelle on souhaite attacher une structure
de sécurité.

    Voici un exemple pour la structure inode, hook d’allocation du champs de sécurité pour
un inode.

    /* include/linux/security.h */

    static inline int security_inode_alloc (struct inode *inode)
    {
            return security_ops->inode_alloc_security (inode);
    }

   Dans les sources du module de sécurité, on trouve le code associé à la gestion du
champs, à nouveau un exemple pour SELinux :

    /* security/selinux/hooks.c */

    static int inode_alloc_security(struct inode *inode)
    {
            struct task_security_struct *tsec = current->security;
            struct inode_security_struct *isec;

            isec = kmalloc(sizeof(struct inode_security_struct), GFP_KERNEL);
            if (!isec)
                    return -ENOMEM;

            memset(isec, 0, sizeof(struct inode_security_struct));
            init_MUTEX(&isec->sem);
            INIT_LIST_HEAD(&isec->list);
            isec->magic = SELINUX_MAGIC;
            isec->inode = inode;
            isec->sid = SECINITSID_UNLABELED;
            isec->sclass = SECCLASS_FILE;
            if (tsec && tsec->magic == SELINUX_MAGIC)
                    isec->task_sid = tsec->sid;
            else
                    isec->task_sid = SECINITSID_UNLABELED;
2       LINUX SECURITY MODULES                                                        11


               inode->i_security = isec;

               return 0;
    }

Mise à jour des Champs
    Il est également nécessaire de mettre à jour ces champs de sécurité. D’autres hooks
ont été insérés, ils sont nommés _post_. Le contrôle d’accès est d’abord
vérifié, et dans le cas d’un succès, la mise à jour du champs est appelé.

        Voici un exemple pour la création d’un lien symbolique :

        – le hook de contrôle d’accès

           /* include/linux/security.h */

           static inline int security_inode_symlink (struct inode *dir,
                                                     struct dentry *dentry,
                                                     const char *old_name)
           {
                   return security_ops->inode_symlink (dir, dentry, old_name);
           }


        – le hook de mise à jour

           /* include/linux/security.h */

           static inline void security_inode_post_symlink (struct inode *dir,
                                                           struct dentry *dentry,
                                                           const char *old_name)
           {
                   security_ops->inode_post_symlink (dir, dentry, old_name);
           }


        – la création d’un lien symbolique

           /* fs/namei.c */

           int vfs_symlink(struct inode *dir, struct dentry *dentry,
                           const char *oldname)
           {
                   int error;
2   LINUX SECURITY MODULES                                                               12


                  down(&dir->i_zombie);
                  error = may_create(dir, dentry);
                  if (error)
                          goto exit_lock;

                  error = -EPERM;
                  if (!dir->i_op || !dir->i_op->symlink)
                          goto exit_lock;

                  error = security_inode_symlink(dir, dentry, oldname);
                  if (error)
                          goto exit_lock;

                  DQUOT_INIT(dir);
                  lock_kernel();
                  error = dir->i_op->symlink(dir, dentry, oldname);
                  unlock_kernel();

        exit_lock:
                up(&dir->i_zombie);
                if (!error) {
                        inode_dir_notify(dir, DN_CREATE);
                        security_inode_post_symlink(dir, dentry, oldname);
                }
                return error;
        }


2.2.3   Communication avec l’espace utilisateur
    Il est relativement facile d’ajouter des données de contrôle en utilisant les champs de
sécurité. Toutefois, cela se passe uniquement en espace noyau. Pourtant un utilisateur
pourrait très bien souhaiter connaître, si la politique de sécurité le permet, ses propres
permissions, ou celles nécessaires sur certains objets. On peut imaginer une commande
lsperm, renvoyant les permissions.

    Il est donc nécessaire de fournir une interface entre l’espace utilisateur (espace d’ap-
pel de la commande lsperm) et l’espace noyau (espace où sont stockées les informations
de sécurité)

   La première solution envisagée fut la mise en place d’un appel système sys_security().
Cette solution ne fut pas retenue, pour deux raisons :

    – pour éviter de mettre en place un appel système non standard,
    – mais surtout qui servirait à tout ou rien, puisque sa fonction serait propre à chaque
      module.
2   LINUX SECURITY MODULES                                                                   13



     La solution actuellement retenue repose sur le système de fichiers /proc, mais chaque
LSM est libre de faire comme bon lui semble. L’architecture intègre dans la structure secu-
rity_operations deux pointeurs sur fonction destinés à communiquer avec l’espace utilisa-
teur via /proc.
/* security/selinux/hooks.c */

int (*getprocattr)(struct task_struct *p,
                   char *name,
                   void *value,
                   size_t size)

int (*setprocattr)(struct task_struct *p,
                   char *name,
                   void *value,
                   size_t size)
    Les répertoires /proc// contiennent maintenant un répertoire attr/, qui contient les
entrées correspondant aux labels de sécurité que l’on souhaite connaître, ou même fixer.

    Ces entrées appellent directement les fonctions précédentes, avec le paramètre name
valant le nom du fichier dans attr/ auquel nous accédons.

2.2.4   Tests de consistance
     Une des grosses difficultés des politiques de contrôle d’accès, est de pouvoir prouver
leur consistance.
Il faut donc parvenir à montrer que l’architecture LSM est consistante c’est à dire qu’elle
n’oublie pas de contrôler un point particulier qui permettrait de contourner un autre point de
contrôle. La consistance d’une politique d’accès pour une ressource est donc de contrôler
tous les moyens qui permettent l’accès à cette ressource.

   Cette consistance n’est pas réellement prouvable au sens mathématique, vu le travail
que nécessiterait la modélisation du noyau Linux.

    Cependant des travaux très intéressants ont été menés par Zhang[1], Edwards et Jae-
ger. Ces travaux ont abouti au document Using CQUAL for Static Analysis of Authorization
Hook Placement pour atteindre un degré de confiance correct. L’objectif de leurs travaux
a donc été de prouver la correction des placements des hooks. Pour cela, ils ont utilisé
CQual[2], un outil d’analyse statique basé sur le typage. Il permet d’ajouter des attributs
aux types, et de calculer la correction à partir de règles d’inférence avec les attributs. C’est
donc un moyen d’ajouter des spécifications aux programmes.

Complete mediation
   Cette vérification se déroule en deux étapes. Tout d’abord il s’agit de s’assurer de la
complétude du principe de médiation (complete mediation, aussi appelée reference moni-
2    LINUX SECURITY MODULES                                                                       14


tor ).

   Cela signifie que le mécanisme de contrôle d’accès doit être capable d’intercepter et
d’empêcher tous les accès à une ressource. Dans le cas contraire, la sécurité ne peut être
garantie. C’est le problème avec la protection d’un réseau interne, si une seule route per-
met d’atteindre un élément du réseau interne sans passer par le pare-feu, alors ce dernier
ne sert à rien.

   Chaque objet doit donc subir une opération de contrôle par un hook avant d’être utilisé.
Seuls les objets accessibles en espace utilisateur sont concernés.




                        F IG . 3 – preuve du principe de médiation



Complete authorization
    La deuxième étape de la vérification est de s’assurer que toutes les opérations de
contrôle ont bien été effectuées avant l’utilisation d’un objet, pour tous les chemins pos-
sibles entre l’initialisation et l’utilisation. Il s’agit donc de vérifier la complétude de l’autori-
sation.

     Cette opération coule relativement de source une fois le problème de médiation résolu.

Approche suivie
     Cette vérification est effectuée à l’aide des opérations suivantes :
    1. détermination des fonctions qui initialisent les objets
    2. détermination des fonctions qui utilisent les objets
    3. détermination des fonctions qui autorisent les accès aux objets
    4. vérification que toutes les manipulations d’objets dans les fonctions d’autorisations
       sont réalisées après le contrôle d’accès
    5. vérification qu’il n’y ait pas d’affectation de l’objet après son contrôle d’accès
    6. détermination des chemins d’exécution entre l’initialisation et l’utilisation de l’objet
    7. vérification de la présence d’au moins une opération de contrôle dans chaque che-
       min
2   LINUX SECURITY MODULES                                                                   15




                            F IG . 4 – preuve de l’autorisation



Vulnérabilités
    Bien que cette vérification ne permette pas une preuve mathématique de la sécurité
de l’architecture, elle a néanmoins permis d’identifier trois types d’erreur.

    – Inconsistance de la vérification :
      La variable qui est vérifiée n’est pas celle qui sera utilisée par la suite. Une condition
      de concurrence (race condition) a été identifiée, pouvant conduire à une exploitation.
      Une preuve de concept a été montrée. La vérification était effectuée sur un objet de
      type struct file, mais la suite des opérations sur le descripteur de fichiers.

    – Modification d’un objet contrôlé sans vérification de sécurité :
      Cela se produit lorsqu’un objet non contrôlé, mais censé avoir été contrôlé, est uti-
      lisé. Un exemple d’une telle situation était le suivant : Une page fault se produisait,
      l’objet file manipulé dans ce cas n’a pas subi de contrôle d’accès. Il est toutefois
      passé à la fonction page_cache_read qui appelle une sous-fonction pour lire la page
      en question, en prenant l’objet file en argument.
      Cet exemple illustre que la lecture d’un fichier après mmap(), ne se soucie pas
      d’éventuelles modifications des attributs de sécurité du fichier, une fois celui-ci mis
      en mémoire. Désormais, le contrôle n’est systématique que pour les fichier non mis
      en mémoire (par mmap()), les fichiers mis en mémoire n’étant contrôlés qu’au mo-
      ment de la lecture pour chargement.

    – Problème de typage :
      Ce problème survient lorsqu’une opération est réalisée sur un objet d’un type donné,
      alors que c’est un autre type qui est attendu.

    L’analyse des auteurs s’appuie sur une analyse statique du typage des objets, qui sont
soit checked soit unchecked.
2   LINUX SECURITY MODULES                                                                 16


Conclusion sur la consitance
     Le problème de l’approche des auteurs est un taux très élevé de faux positifs, c’est à
dire d’endroits où l’analyseur détecte une faille alors qu’il n’y en a pas. Malgré cela, ces
travaux ont permis de donner une garantie de sécurité, non absolue mais suffisante, à
l’architecture des LSM.


2.2.5   Enregistrement et empilage des LSM
Enregistrement
    Nous avons vu qu’un module de sécurité est en fait un tableau de pointeurs sur des
fonctions. Pour qu’il soit utilisé, il est nécessaire de signaler au noyau son enregistrement.
Cela se fait au chargement du module par l’appel à la fonction register_security().
De la même manière, le déchargement est effectué par l’appel à la fonction unregis-
ter_security().


Empilement
   Il peut-être souhaitable de combiner plusieurs module de sécurité, afin de bénéficier
de plusieurs politiques de contrôle d’accès.

    Lorsqu’un module est déjà enregistré, l’appel à la fonction register_security() échouera.
Il est cependant possible de s’enregistrer auprès du module déjà enregistré en appelant
mod_reg_security().

   L’accord de chargement dépendra de celui-ci. S’il accepte, les appels aux hooks dé-
pendront également de celui-ci. Il est possible que les demandes d’autorisation ne soit pas
systématiques.

    Dans la situation où un module A est dépendant d’un autre module B, lorsque le mo-
dule B se décharge, le module B devrait appeler la fonction mod_unreg_security() du mo-
dule A avant de se décharger.

    Lorsque plusieurs modules sont chargés, ces modules constituent en fait une liste.
Chaque module est alors en charge d’appeler, s’il le souhaite, les contrôles du module
suivant.
2       LINUX SECURITY MODULES                                           17


Exemple standard
    /* LSM-standard */

    /* 1 si présence d’un autre module avant */
    static int secondary;


    /* définition des opérations du module */
    struct security_operations facist_ops = {
    ...
    }

    static int init_module(void)
    {
    ...
            /* enregistrement */
            if (register_security(&facist_ops)) {
               printk(KERN_INFO "échec de l’enregistrement\n");
               /* tentative en contactant le module précédent */
               if (mod_reg_security(MY_NAME, &facist_ops)) {
                  printk(KERN_INFO "échec auprès module précédent\n");
                  return -EINVAL;
               }
               secondary = 1;
            }
            printk(KERN_INFO "facist LSM chargé\n");
            return 0;
    }


    static void exit_module(void)
    {
            /* on se retire de l’architecture LSM */
            if (secondary) {
               if (mod_unreg_security(MY_NAME, &facist_ops)) {
                  printk(KERN_INFO "échec du déchargement secondaire\n");
                  return;
               }
            }

            if (unregister_security(&facist_ops)) {
               printk(KERN_INFO "échec du déchargement\n");
            }
    }
2    LINUX SECURITY MODULES                                                          18


  Un module de sécurité doit également prévoir le chargement et le déchargement d’un
module secondaire.

    /* pointeur sur les hooks du successeur */
    struct security\_operations *next\_ops;

    Un module de sécurité peut consulter systématiquement un autre module pour l’auto-
risation du reboot :

    static int facist_reboot(unsigned int cmd)
    {
            int res = -EPERM;
            if (next_ops->reboot)
               res = next_ops->reboot(cmd);
            return -EPERM;
    }

     ou ne jamais consulter l’autre module :

    static int facist_reboot(unsigned int cmd)
    {
            return -EPERM;
    }


SELinux
    SELinux ne peut pas être chargé comme module secondaire. Il ne possède pas la va-
riable int secondary et la fonction de chargement mod_reg_security() SELinux permet le
chargement secondaire des modules dummy, capability et owlsm (cf. security/selinux/hooks.c).


    /* security/selinux/hooks.c */

    struct security_operations selinux_ops = {
            .ptrace =                       selinux_ptrace,
            .capget =                       selinux_capget,
            .capset_check =                 selinux_capset_check,

    ...
            .inode_alloc_security =                selinux_inode_alloc_security,
            .inode_free_security =                 selinux_inode_free_security,
    ...
            .inode_symlink =                       selinux_inode_symlink,
    ...
            .register_security =                   selinux_register_security,
    ...
2    LINUX SECURITY MODULES                          19


          .getprocattr =      selinux_getprocattr,
          .setprocattr =      selinux_setprocattr,
    ...
    }
3     ARCHITECTURE DE SELINUX                                                              20


3      Architecture de SELinux
    SELinux est basé sur le modèle de l’architecture Flask , que nous allons détailler. Il
a été conçu tout d’abord sous forme de patch pour le noyau Linux. Puis, avec la création
des LSM, il a progressivement évolué vers une implémentation utilisant ce framework de
sécurité dans le noyau, apportant d’ailleurs une forte contribution au développement du
projet LSM.


3.1    Mandatory Acces Control
    La politique de contrôle d’accès typique d’un système Unix est laissée à la discrétion
de l’utilisateur. C’est le DAC, ou Discretionary Acces Control. La protection apportée par
SELinux est fondée sur la principe de MAC, Mandatory Acces Control. Le MAC s’appuie
sur l’utilisation de labels associés à des sujets (processus) et à leurs objets (fichiers, so-
ckets...). Son but est alors de vérifier, à partir d’une politique de sécurité prédéfinie, la
légitimité de tous les accès des sujets aux objets. Ici, l’utilisateur n’est plus maître des
objets qu’il possède, et c’est ce qui permet de baisser par exemple les capacités de root.

     Le MAC n’est cependant pas l’apport principal de SELinux. C’est en fait l’utilisation de
l’architecture Flask , déployée dans le noyau pour implémenter le MAC.


3.2    Le modèle Flask
   Flask est une sorte de charpente autorisant l’implémentation de différents modèles de
sécurité. Il a donné lieu plus tard à la création des LSM, par Linus Torvalds et sa commu-
nauté.

    Flask repose sur la séparation entre le code de décision et le code d’application de
la politique de sécurité. La partie décisionnelle de l’architecture de SELinux est conte-
nue dans un composant particulier du noyau, et établit les lois à appliquer sur le système.
C’est le référentiel de sécurité. La partie d’application est elle intégrée directement dans
les composants du noyau gérant les processus, les systèmes de fichiers, les IPC et le
réseau.

    Enfin, SELinux supporte un cache, pour l’accès rapide aux décisions déjà calculées.
C’est l’Access Vector Cache, ou AVC.
Ce modèle devant être indépendant de la polique de sécurité à appliquer, les intéractions
sujets-objets sont modélisées : Chaque entité du système reçoit un label, ou contexte de
sécurité. Il contient les informations relatives à cette entité, pour déterminer avec qu’elles
autres entités, et comment, elle peut intérargir. Ces contextes sont associés à un entier
pour simplifier leur manipulation, le Security IDentifier, ou SID. Dans le cas des fichiers
enregistrés sur des mémoires de masse, les SID deviennent persistants et sont enregis-
trés directement dans le système de fichier. Ce sont les PSID. Les objets du systèmes
se voient de plus attribuer une classe, à laquelle sont associées des permissions. (par
exemple la classe ’file’, avec les permissions ’open’ ou ’link ’).
3     ARCHITECTURE DE SELINUX                                                                  21


     Les décisions du référentiel de sécurité reposent donc sur les contextes de sécurité
attribués au couple (sujet,objet) et sur la classe de l’objet. Ces décisions sont de deux
types, accès et transition.

    Les décisions d’accès spécifient si une certaine permission est accordée ou refusée
pour un couple de SID (source et cible), et la classe de l’objet cible. Le SID source est celui
du sujet, le SID cible est celui de l’objet. Concrètement, le référentiel de sécurité fournit un
tableau de l’ensemble des permissions associées à la classe de l’objet pour le couple de
SID source et cible. (C’est ce tableau qui est enregistré dans l’AVC). Il fournit aussi deux
tableaux qui spécifient les besoins de journalisation (audit) associés à la classe de l’objet
(auditallow en cas de succès, auditdeny en cas d’echec).

   Les décisions de transitions attribuent des labels aux nouveaux objets, et existent sous
deux formes :
   – transition de processus
   – transition d’objet

   Une décision de transition de processus a lieu lors de l’exécution d’un nouveau pro-
gramme, à partir du SID du processus demandant et du SID du fichier à exécuter.

    Une décision de transition d’objet a lieu lors de la création d’un nouvel objet, à partir du
SID du programme créant l’objet et du SID d’un objet ’parent’. Par exemple le dossier pa-
rent s’il s’agit d’un fichier. De plus, une application peut fournir directement le label attribué
au nouvel objet, en utilisant des fonctions de SELinux. Cette application doit cependant
être autorisée à modifier le contexte de sécurité et une telle transition doit être permise par
une décision d’accès correspondante. Par exemple, un utilisateur se connectant via SSH
va recevoir un SID lui correspondant, et non le SID par défaut.


3.3     Modèles de sécurité
    SELinux offre la possibilité d’utiliser différents modèles de sécurité. Si les possibilités
seront différentes suivant le modèle choisi, les principes de fonctionnement vont eux rester
inchangé. Le modèle implémenté actuellement est une combinaison de Type Enforcement
et de Role-Based Access Control (RBAC).

  Une implémentation de Multi-Level Security est en cours mais reste encore expéri-
mentale, ainsi qu’une implémentation de Labeled Networking Support.


3.3.1   Type Enforcement
    Le modèle de security Type Enforcement (TE) est dérivé du modèle Domain and Type
Enforcement (DTE). Dans DTE, tous les objets et processus du système reçoivent des at-
tributs de sécurité. Ils sont nommés domaines pour les processus et types pour les objets.
Les processus d’un même domaine et les objets d’un même type sont traités de façon
identique.
3   ARCHITECTURE DE SELINUX                                                                    22


    Le modèle TE diffère de l’original par le fait qu’il n’a q’un seul type d’attributs de sé-
curité. Les domaines sont en fait des types qu’il faut associer à des processus pour se
rapprocher au mieux de DTE. En pratique, la définition d’un type ou d’un domaine devient
identique, SELinux ne faisant plus de différence en interne.

    Une autre différence de SELinux par rapport au modèle original est la notion de classe
d’objet qui provient de Flask . Deux objets du même type mais de classe différente peuvent
alors être traités différemment, ce qui permet donc un contrôle très fin des exécutions et
transitions de domaines.

     Enfin, TE n’associe pas les utilisateurs directement à des domaines, mais à des rôles.
Un rôle détermine quels domaines peuvent être utilisés. TE permet alors de définir des lois
d’accès et de transition, avec pour chacun de ces deux types un comportement par défaut.
Ainsi, une demande d’accès donnée est refusée si aucune loi n’existe qui lui correspond.
Pour les transitions, SELinux se base sur la conservation du domaine pour les processus,
et l’héritage du type du parent pour les objets.


3.3.2   Role-Based Access Control
     Le modèle original de RBAC assigne des rôles aux utilisateurs, et des permissions à
ces rôles. SELinux associe à chaque utilisateur un ensemble de rôles, et à chaque rôle
un ensemble de domaines de TE. Il combine ainsi les facilités de gestion du RBAC et la
finesse de contrôle de TE. Les rôles sont inclus dans les contextes de sécurité associés
aux sujets et objets du système. Puisque SELinux permet de définir des règles de tran-
sition de rôles pour les processus, les UID traditionnelles de Linux ne conviennent plus.
En effet, un programme lancé par root peut prendre n’importe quelle UID via les fonctions
set*uid.

      SELinux introduit donc un attribut indépendant de l’UID, et définissant l’identité de
l’utilisateur dans le contexte de sécurité. Il peut ainsi effectuer des contrôles sur l’identité
de l’utilisateur sans perturber le DAC.
      En pratique, seuls certains domaines ont la possibilité de modifier l’identité d’un utilisa-
teur. Les programmes login et sshd font par exemple partie de ces domaines. L’avantage
certain procuré par de tels mécanismes et une meilleure traçabilité des utilisateurs. Un
utilisateur utilisant la fonction su conservera toujours son identité SELinux.
3   ARCHITECTURE DE SELINUX                                                            23


3.3.3   Multi-Level Security
   C’est un cas particulier de MAC. Le label d’un objet spécifie alors le niveau minimal
que doit avoir un sujet pour accéder à cet objet. L’on définit par exemple 4 labels (top
secret, secret, confidentiel et non classifié).
Puis on définit 2 règles systématiquement appliquées :
   – read down : l’accréditation d’un sujet doit dominer le niveau de sécurité de l’objet
      qu’il lit
   – write up : l’accréditation d’un sujet doit être dominée par le niveau de sécurité de
      l’objet qu’il écrit

   On garantit (mathématiquement) ainsi la confidentialité des objets en fonction des ni-
veaux d’accréditation. C’est le modèle Bell-La Padula (BPL). Le modèle MLS prévu dans
SELinux en est très proche.

    Notons que le modèle inverse (read up, write down), ou modèle de Biba, garantit quant
à lui l’intégrité des données.

    Notons de plus que l’implémentation de MLS au sein de SELinux n’est pas encore
terminée. Au stade expérimental où elle se trouve actuellement, il est déjà possible d’as-
socier ces niveaux de confidentialité à toutes les entités du système.



3.3.4   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 de LNS est de pou-
voir associer les paquets IP à des SID. Ces paquets seront décodés par le destinataire du
traffic, selon le protocole Security Context Mapping Protocol (SCMP).

   LNS ne peut être mis en place que sur un parc de machines où les politiques SELi-
nux sont équivalentes, ce parc devant être déclaré dans la configuration de la politique.
Ce modèle ne définit cependant pas de protection du trafic, qui doit alors être apporté de
manière annexe.

   Dans la documentation actuelle de SELinux et dans les implémentations existantes,
quelque soit la distribution, nous n’avons vu aucun exemple concret de mise en place
de LNS. Ce modèle repose en effet sur un parc de machines, et SELinux n’est pour le
moment supporté que sur des serveurs, et là rien n’a encore été prévu pour une gestion
simple ainsi que la propagation d’une politique de sécurité.
4     INTÉGRATION DE SELINUX                                                               24


4      Intégration de SELinux
     Si la partie de SELinux implémentant les LSM fait partie du noyau, il reste plusieurs
utilitaires et démons à modifier afin de prendre en compte l’environnement SELinux.


4.1    dans le noyau
    Si l’on se place dans le répertoire contenant les sources du noyau (usr/src/linux), on
trouve le dossier security. Il contient les modules utilisant l’architecture LSM, ainsi que le
code spécifique à SELinux, dans selinux/.

   SELinux implémente l’ensemble des ancres fournis par LSM, les fonctions correspon-
dantes étant définies dans le fichier hooks.c.


4.2    dans les démons et utilitaires
    La principale librairie utilisée par les programmes pour accèder aux fonctions de com-
munication avec l’environnement SELinux est libsecure. Cette bibliothèque fournit des
mécanismes propre à LSM permettant à SELinux, qui se trouve dans l’espace noyau,
d’intéragir avec les processus standards. Cette communication se fait par des entrées
spécifiques dans /proc.

    Deux catégories de programmes utilisent libsecure :
    – les démons et utilitaires classiques modifiés (sshd, login, ls, ps...)
    – les nouveaux utilitaires fournis avec SELinux (runas, setfiles, checkpolicy...), qui
      permettent entre autre d’assigner des labels au système de fichier, ou de manipuler
      la politique de sécurité.
5   ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE                                                25


5     Etude de la mise en œuvre sur Mandrake
5.1    Contexte
    Cette étude pratique est réalisée dans le cadre du projet proposé par le service des
Moyens Informatiques (MI) du Loria (Laboratoire lOrrain de Recherche en Informatique
et ses Applications). La problématique initialement proposée était de tester SELinux sur
la distribution Linux officiellement utilisée dans ce centre de recherche avec un certain
nombre de contraintes fonctionnelles que nous allons décrire par la suite.


5.2    Objectifs
    Les deux objectifs initiaux de ce projet étaient :

    – l’étude du système SELinux (installation, compréhension du fonctionnement, confi-
      guration des options) et de ses différentes fonctionnalités

    – la mise en situation pratique de SELinux dans le cadre de la réalisation d’un ser-
      veur d’accès externe SSH. Ce serveur d’accès a pour fonction de fournir un accès au
      réseau interne via SSH aux utilisateurs du Loria se trouvant sur un réseau extérieur.

   Le premier objectif a été réalisé. Le second n’a pas pu aboutir du fait de contraintes
spécifiques...


5.3    Contraintes
    Les contraintes apparues sont directement liées au contexte dans lequel cette étude
s’est réalisée. Nous pouvons les résumer comme suit :

    – La distribution Linux utilisée doit être une Mandrake, et plus particulièrement celle
      utilisée au Loria.

    – Les comptes des utilisateurs du système à étudier sont des comptes itinérants, ac-
      cessible par le couple de services NIS et NFS.

    – Un utilisateur doit pouvoir utiliser ses outils habituels, contrainte que nous avions,
      dès le démarrage du projet et au vues des problèmes de configuration des poli-
      tiques de sécurité, restreint à l’utilisation de SSH, de Mozilla, de XEmacs et de Vim.

    À partir du moment où il nous a été imposé l’utilisation de la distribution Mandrake
nous avons manifesté quelques réticences face à ce choix. La principale justification que
nous avions reste celle couramment évoquée lorsque l’on traite de SELinux, à savoir que
SELinux n’est pas destiné a être utilisé sur une distribution de type station de travail mais
plutôt pour un serveur. Ce point est important car nous verrons par la suite qu’il est la
cause initiale d’un manque total de support sur SELinux pour cette distribution.
5   ETUDE DE LA MISE EN ŒUVRE SUR MANDRAKE                                                   26


5.4    Réalisation
    Nous ne parlerons pas ici de la partie installation et administration de la machine qui
nous a été livrée “vierge”. Toutefois il est important pour la suite de noter deux particulari-
tés de cette installation :

    – la distribution Mandrakefournie est spécifique au Loria et a été installée entière-
      ment (installation par défaut, avec tous les paquets proposés).

    – les comptes utilisateurs sont itinérants, authentifiés via NIS et montés via NFS

    La partie “hardware” quant à elle n’a aucune incidence, si ce n’est l’espace mémoire
vive disponible qui, nous le verront plus loin, constitue un réel problème pour le montage
des répertoires des utilisateurs.

    Le travail effectif sur l’étude de SELinux a commencé par la recherche d’un noyau
2.4.X SELinux pour la distribution Mandrake, la branche 2.6.X nous est apparue encore
trop risquée du fait de sa jeunesse relative et des dépendances qu’elle imposait (sur les
nouveaux outils de gestion des modules en l’occurrence). Nous avons fini par compiler
notre propre noyau, non sans mal, ce sera expliqué plus loin.

     Une fois notre noyau apte, notre second travail a été de mettre en place les outils
propres à SELinux. Ces outils permettent d’accéder depuis l’espace utilisateur aux fonc-
tions avancées des modules de sécurité de SELinux et assurent, entre autre, la gestion
et le chargement des politiques de sécurité. Nous verrons qu’il est coûteux en temps, du
fait du manque de support, de disposer de ces outils sous Mandrake.

    Une fois ces outils disponibles nous avons tenté plusieurs chargements de politiques
rendant de manière systématique l’ensemble du système inutilisable. Et comme aucun
“patch” ni aucun paquet de base de la distribution Mandrake supportant SELinux n’était
disponible, l’exploration de SELinux sur celle-ci s’est arrêtée là.
En effet le temps nécessaire pour refaire l’ensemble minimal des éléments de base du sys-
tème pour que SELinux soit fonctionnel sous Mandrake a fait que le projet initial n’était
pas du tout réalisable dans les temps impartis et ne nous a pas permis d’aller plus en
avant. Tout est détaillé dans la section suivante.

     Concernant le travail effectué, dans le but initial de ce projet, nous regrettons toutefois
de ne pas avoir eu accès à un système sous SELinux qui soit fonctionnel et donc d’avoir
pu réaliser le moindre test probant sur celui-ci, ni tenté la mise en place d’au moins une
politique particulière souhaité à l’origine. Nous avons noté, à titre indicatif et personnel,
qu’à partir de l’installation d’une distribution Debian minimale (juste le support du réseau)
et l’ajout de quelques sources apt supplémentaires, la mise en place d’un système minimal
sous SELinux reste beaucoup plus abordable : tout est fourni, noyau, outils SELinux,
version SELinux des outils du système de base, librement.
Vous pouvez aussi lire
Partie suivante ... Annuler