En 2000, la NSA (National Security Agency) met SELinux à disposition de la communauté, comme preuve du concept (poc : proof of concept) de contrôle d’accès obligatoire (MAC : mandatory access control) dans une architecture FLASK (Flux Advanced Security Kernel, cf. Fluke OS).
Avant de l’accepter comme partie intégrante du noyau, Linus Torvalds exige le développement d’une architecture spécifique permettant un chargement modulaire de futures autres nouvelles fonctionnalités de sécurité. C’est ainsi que naît l’API (Application Programming Interface) LSM (Linux Security Modules).
LSM est un cadre de travail (framework) pour la sécurité et fait partie intégrante du noyau Linux depuis la version 2.6. Il est intégré aux parties du noyau qui contrôlent l’accès aux fichiers, aux interfaces réseau, … Une fois porté sur l’API LSM, le code SELinux a été intégré au noyau.
La première distribution à supporter SELinux fût la Fedora Core, pilotée par Red Hat. Aujourd’hui SELinux est supporté par la grande majorité des autres distributions, parmi lesquels Gentoo et plus récemment Debian.
Pour déterminer si SELinux est activé sur un système, il faut utiliser
la commande getenforce
, qui — si elle est présente — renvoie le mode
courant du système parmi les 3 états existants : actif (enforcing),
désactivé (disabled) ou permissif (permissive). Ce dernier état
ne bloque aucun accès mais journalise toutes les vérifications de la
politique effectuées.
SELinux décompose le système d’exploitation en deux catégories : les sujets et les objets.
Les sujets sont les processus et autres éléments « actifs », comme les utilisateurs ou les applications. Ils peuvent être de confiance ou pas.
Les objets, à l’inverse, sont les fichiers, ports de connexion (sockets), tubes, interfaces et toute autre entité plus statique qu’on peut trouver au sein du système.
À chaque objet est assigné un contexte de sécurité de type définissant qui (quel sujet) peut l’utiliser et comment (pour quoi faire).
<cible> <sujet> <objet>:<classe> { <permission1> <permission2> }
allow named_t sbin_t:dir search
named_t
sur les objets de type
sbin_t
de la classe dir
(répertoire) à effectuer des
recherches
SELinux est fondé sur ce concept, appelé renforcement du type (TE : type enforcement).
Sur chaque partie du système d’exploitation — des utilisateurs aux fichiers en passant par les ports TCP, SELinux appose une étiquette (label) définissant les politiques de sécurité qui affectent cet objet et fournit un contexte d’utilisation.
SELinux assigne automatiquement les étiquettes aux éléments du système, mais l’administrateur peut modifier celles-ci selon ses besoins, la politique s’appliquant suivant les étiquettes et non suivant les fichiers.
Une clé de SELinux est la compréhension et l’utilisation des contextes SELinux. Chaque élément du système est associé à un contexte, et ces contextes sont utilisés pour déterminer quels utilisateurs, applications et services ont accès à quels fichiers, répertoires et applications. Sans même comprendre le détail du mécanisme de création d’une politique de sécurité, la plupart des utilisateurs de SELinux peut gérer ses système est utilisant et modifiant les contextes.
Il existe trois type des contextes dans SELinux. Pour visualiser les
contextes d’un répertoire ou d’un fichier, il suffit d’utiliser la
commande ls
avec l’option longue --context
ou l’option courte
-Z
:
[olm@olm www]$ ls -Z /var/www
drwxr-xr-x. root root system_u:object_r:httpd_sys_content_t:s0 html
NB : Ces options s’appliquent à de nombreuses autres commandes et
permettent de connaître le contexte de sécurité des utilisateurs
(id
, …), des processus (ps
, ss
, lsof
, …).
Dans le résultat fourni par la commande, c’est la partie suivante
qu’il faut examiner : system_u:object_r:httpd_sys_content_t
.
On y trouve les trois contextes du répertoire :
system_u
est le contexte utilisateur,object_r
est le contexte de rôle utilisé seulement dans le
cadre d’une application stricte,httpd_sys_script_exec_t=
est le contexte de type.Il peut prendre trois valeurs :
user_u
indique que n’importe quel utilisateur peut accéder au
fichier (nonobstant les droits POSIX qui s’appliquent avant
SELinux),system_u
indique que seuls les utilisateurs système peuvent
accéder au fichier,root
indique que seul l’utilisateur ayant l’UID 0 peut accéder
au fichier.C’est le contexte le plus important, sur lequel il faut porter son
attention lorsque l’on modifie les permissions SELinux ou que l’on
dépanne un système SELinux. Ce sont les contextes de type qui
fournissent le contrôle d’accès le plus fin dans SELinux. Un système
SELinux avec une politique par défaut présente un grand nombre de
contextes de type. La commande semanage fcontext -l
permet de les
lister.
NB : les éléments entre parenthèses sont des expressions rationnelles.
[olm@olm ~] sudo semanage fcontext -l | grep "httpd_sys_content"
/srv/([^/]*/)?www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/www(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/etc/htdig(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/srv/gallery2(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/trac(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/htdig(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/www/icons(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/glpi(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/htdig(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/drupal.* all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/z-push(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/www/svn/conf(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/icecast(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/var/lib/cacti/rra(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/ntop/html(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/doc/ghc/html(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/openca/htdocs(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
/usr/share/selinux-policy[^/]*/html(/.*)? all files system_u:object_r:httpd_sys_content_t:s0
Même si activée la politique SELinux peut ne pas concerner l’ensemble du fonctionnement du système d’exploitation. Le périmètre d’application de la politique SELinux peut être :
SELinux permet également la création de rôles utilisables pour un contrôle d’accès fondé sur les rôles (RBAC : role-base access control), au sein duquel les utilisateurs (au sens SELinux : ce ne sont pas nécessairement ceux du système) sont associés à un ou plusieurs rôles, des accès leur étant fournis suivant les permissions associées à leur différents rôles. Cet ensemble de fonctionnalités de sécurité (TE et RBAC) encourage les utilisateurs sur la voie du « moindre privilège », en refusant les accès par défaut pour n’autoriser que les utilisateurs appropriés, les fichiers et applications suivant le contexte donné.
semodule
)setenforce
)getsebool
, setsebool
/etc/selinux
/etc/selinux/<politique>
/sys/fs/selinux
/usr/share/selinux
/var/log/audit/audit.log
chcon
, restorecon
,
semanage fcontext
, /.autorelabel
, …/sys/fs/selinux
init
type=AVC msg=audit(1133209488.535:344): avc: denied { getattr } for pid=4198 comm="httpd" name="toto.html" dev=dm-0 ino=3438923 scontext=root:system_r:httpd_t tcontext=system_u:object_r:httpd_private_content_t tclass=file
type=AVC
: Cache de vecteurs d’accèsmsg=audit(1133209488.535:344)
: identifiant du messageavc: denied { getattr }
: résultat, obtention d’un attribut
refusépid=4198
: identifiant du processus sujet concernéscontext=root:system_r:httpd_t
: contexte de sécurité du
sujetdev=dm-0
: périphérique où est stocké l’objetino=3438923
: numéro d’inode de l’objettcontext=system_u:object_r:httpd_private_content_t
:
contexte de sécurité de l’objettclass=file
: classe d’objetausearch -m AVC
audit2allow
dontaudit
)aureport
, auditctl
,
audit2why
Last edited by Olm, 2017-09-28 13:56:05