newrole -r role_r -t domaine_t
(il n'y a généralement qu'un seul domaine possible pour un rôle donné et le paramètre -t
est donc souvent inutile). Cette commande demande à l'utilisateur son mot de passe afin de l'authentifier. Cette caractéristique empêche tout programme de pouvoir changer de rôle de manière automatique. De tels changements ne peuvent avoir lieu que s'ils sont prévus dans l'ensemble de règles.
ssh
est étiqueté avec ssh_exec_t
et lorsque le programme est démarré, il bascule automatiquement dans le domaine ssh_t
). Ce mécanisme de changement automatique de domaine permet de ne donner que les droits nécessaires au bon fonctionnement de chaque programme et est à la base de SELinux.
apt install selinux-basics selinux-policy-default
command will automatically install the packages required to configure an SELinux system.
selinux-policy-default
contient un ensemble de règles standard. Par défaut, l'ensemble de règles ne restreint les accès que pour certains services très exposés. Les sessions utilisateur ne sont pas restreintes et il n'y a donc que peu de risques que SELinux bloque des opérations légitimes des utilisateurs. En revanche, cela permet d'apporter un surcroît de sécurité pour les services système fonctionnant sur la machine. Pour obtenir l'équivalent des anciennes règles « strictes », il faut simplement désactiver le module unconfined
(la gestion des modules est détaillée plus loin).
fixfiles relabel
.
selinux=1 security=selinux
parameter to the Linux kernel. The audit=1
parameter enables SELinux logging which records all the denied operations. Finally, the enforcing=1
parameter brings the rules into application: without it SELinux works in its default permissive mode where denied actions are logged but still executed. You should thus modify the GRUB bootloader configuration file to append the desired parameters. One easy way to do this is to modify the GRUB_CMDLINE_LINUX
variable in /etc/default/grub
and to run update-grub
. SELinux will be active after a reboot.
selinux-activate
automatise ces opérations et permet de forcer un étiquetage au prochain redémarrage, ce qui évite d'avoir des fichiers non étiquetés créés alors que SELinux n'était pas encore actif et que l'étiquetage était en cours.
semodule
. En outre, il faut pouvoir définir les rôles accessibles à chaque utilisateur ; pour cela c'est la commande semanage
qu'il faudra utiliser.
/etc/selinux/default/
. Contrairement à ce qui se pratique d'habitude avec les fichiers de configuration de /etc/
, ces fichiers ne doivent pas être modifiés manuellement. Il faut les manipuler en utilisant les programmes prévus pour cela.
/usr/share/selinux/default/
directory. To enable one of these modules in the current configuration, you should use semodule -i module.pp.bz2
. The pp.bz2 extension stands for policy package (compressed with bzip2).
semodule -r module
. Finally, the semodule -l
command lists the modules which are currently installed. It also outputs their version numbers. Modules can be selectively enabled with semodule -e
and disabled with semodule -d
.
#
semodule -i /usr/share/selinux/default/abrt.pp.bz2
#
semodule -l
abrt 1.5.0 Disabled accountsd 1.1.0 acct 1.6.0 [...]
#
semodule -e abrt
#
semodule -d accountsd
#
semodule -l
abrt 1.5.0 accountsd 1.1.0 Disabled acct 1.6.0 [...]
#
semodule -r abrt
#
semodule -l
accountsd 1.1.0 Disabled acct 1.6.0 [...]
semodule
recharge immédiatement la nouvelle configuration, sauf si l'on utilise l'option -n
. Signalons également que le programme modifie par défaut la configuration courante (celle indiquée par la variable SELINUXTYPE
dans /etc/selinux/config
) mais qu'on peut en modifier une autre grâce à l'option -s
.
semanage
.
-a
pour ajouter, -d
pour supprimer, -m
pour modifier, -l
pour lister et -t
pour indiquer un type (ou domaine).
semanage login -l
liste les correspondances existantes entre identifiants d'utilisateurs et identités SELinux. Si un utilisateur n'a pas de correspondance explicite, il aura l'identité indiquée en face de __default__
. La commande semanage login -a -s user_u utilisateur
va associer l'identité user_u à l'utilisateur. Enfin, semanage login -d utilisateur
va retirer la correspondance affectée à l'utilisateur.
#
semanage login -a -s user_u rhertzog
#
semanage login -l
Login Name SELinux User MLS/MCS Range Service __default__ unconfined_u SystemLow-SystemHigh * rhertzog user_u SystemLow * root unconfined_u SystemLow-SystemHigh * system_u system_u SystemLow-SystemHigh * #
semanage login -d rhertzog
semanage user -l
liste les correspondances entre identité SELinux et rôles possibles. Ajouter une nouvelle identité nécessite de préciser d'une part les rôles correspondants et d'autre part un préfixe d'étiquetage qui définira le type affecté aux fichiers personnels (/home/utilisateur/*
). Le préfixe est à choisir entre user
, staff
et sysadm
. Un préfixe « staff
» donnera des fichiers typés staff_home_dir_t
. La commande créant une identité est semanage user -a -R rôles -P préfixe identité
. Enfin, une identité peut être supprimée avec semanage user -d identité
.
#
semanage user -a -R 'staff_r user_r' -P staff test_u
#
semanage user -l
Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles root sysadm SystemLow SystemLow-SystemHigh staff_r sysadm_r system_r staff_u staff SystemLow SystemLow-SystemHigh staff_r sysadm_r sysadm_u sysadm SystemLow SystemLow-SystemHigh sysadm_r system_u user SystemLow SystemLow-SystemHigh system_r test_u staff SystemLow SystemLow staff_r user_r unconfined_u unconfined SystemLow SystemLow-SystemHigh system_r unconfined_r user_u user SystemLow SystemLow user_r #
semanage user -d test_u
/srv/www/
accessible au serveur web, on pourrait exécuter semanage fcontext -a -t httpd_sys_content_t "/srv/www(/.*)?"
puis restorecon -R /srv/www/
. La première commande enregistre la nouvelle règle d'étiquetage et la deuxième restaure les bonnes étiquettes en fonction des règles enregistrées.
semanage port -m -t http_port_t -p tcp 8080
.
getsebool
permet de consulter l'état de ces options (getsebool booléen
affiche une option et getsebool -a
les affiche toutes). La commande setsebool booléen valeur
change la valeur courante d'une option. L'option -P
rend le changement permanent, autrement dit la nouvelle valeur sera celle par défaut et sera conservée au prochain redémarrage. L'exemple ci-dessous permet au serveur web d'accéder aux répertoires personnels des utilisateurs (utile dans le cas où ils ont des sites web personnels dans ~/public_html/
par exemple).
#
getsebool httpd_enable_homedirs
httpd_enable_homedirs --> off #
setsebool -P httpd_enable_homedirs on
#
getsebool httpd_enable_homedirs
httpd_enable_homedirs --> on
/usr/share/doc/selinux-policy-doc/html/
) et des fichiers exemples permettant de créer de nouveaux modules. Installons ces fichiers pour les étudier de plus près :
$
cp /usr/share/doc/selinux-policy-doc/Makefile.example Makefile
$
cp /usr/share/doc/selinux-policy-doc/example.fc ./
$
cp /usr/share/doc/selinux-policy-doc/example.if ./
$
cp /usr/share/doc/selinux-policy-doc/example.te ./
.te
file is the most important one. It defines the rules. The .fc
file defines the “file contexts”, that is the types assigned to files related to this module. The data within the .fc
file are used during the file labeling step. Finally, the .if
file defines the interface of the module: it is a set of “public functions” that other modules can use to properly interact with the module that you're creating.
myapp_domtrans
) sert à contrôler qui a le droit d'exécuter l'application et la seconde (myapp_read_log
) fournit un droit de lecture sur les fichiers de logs de l'application.
.te
. Il faut donc déclarer tous les types employés (avec la macro gen_require
) et employer les directives standard pour attribuer des droits. Notons toutefois qu'il est possible d'employer des interfaces fournies par d'autres modules. La prochaine section en dévoilera plus sur la manière d'exprimer ces droits.
Exemple 14.3. Fichier example.if
## <summary>Myapp example policy</summary> ## <desc> ## <p> ## More descriptive text about myapp. The <desc> ## tag can also use <p>, <ul>, and <ol> ## html tags for formatting. ## </p> ## <p> ## This policy supports the following myapp features: ## <ul> ## <li>Feature A</li> ## <li>Feature B</li> ## <li>Feature C</li> ## </ul> ## </p> ## </desc> # ######################################## ## <summary> ## Execute a domain transition to run myapp. ## </summary> ## <param name="domain"> ## Domain allowed to transition. ## </param> # interface(`myapp_domtrans',` gen_require(` type myapp_t, myapp_exec_t; ') domtrans_pattern($1,myapp_exec_t,myapp_t) ') ######################################## ## <summary> ## Read myapp log files. ## </summary> ## <param name="domain"> ## Domain allowed to read the log files. ## </param> # interface(`myapp_read_log',` gen_require(` type myapp_log_t; ') logging_search_logs($1) allow $1 myapp_log_t:file r_file_perms; ')
example.te
:
policy_module(myapp,1.0.0)######################################## # # Declarations # type myapp_t;
type myapp_exec_t; domain_type(myapp_t) domain_entry_file(myapp_t, myapp_exec_t)
type myapp_log_t; logging_log_file(myapp_log_t)
type myapp_tmp_t; files_tmp_file(myapp_tmp_t) ######################################## # # Myapp local policy # allow myapp_t myapp_log_t:file { read_file_perms append_file_perms };
allow myapp_t myapp_tmp_t:file manage_file_perms; files_tmp_filetrans(myapp_t,myapp_tmp_t,file)
Le module doit être identifié par son nom et par son numéro de version. Cette directive est requise.
| |
Si le module introduit de nouveaux types, il doit les déclarer avec des directives comme celle-ci. Il ne faut pas hésiter à créer autant de types que nécessaires, plutôt que distribuer trop de droits inutiles.
| |
Ces interfaces précisent que le type myapp_t est prévu pour être un domaine de processus et qu'il doit être employé pour tout exécutable étiqueté par myapp_exec_t . Implicitement, cela ajoute un attribut exec_type sur ces objets. Sa présence permet à d'autres modules de donner le droit d'exécuter ces programmes : ainsi, le module userdomain va permettre aux processus de domaine user_t , staff_t et sysadm_t de les exécuter. Les domaines d'autres applications confinées n'auront pas le droit de l'exécuter, sauf si les règles prévoient des droits similaires (c'est le cas par exemple pour dpkg avec le domaine dpkg_t ).
| |
logging_log_file est une interface fournie par la reference policy qui sert à indiquer que les fichiers étiquetés avec le type précisé en paramètre sont des fichiers de logs et doivent bénéficier des droits associés (par exemple ceux permettant à logrotate de les manipuler).
| |
La directive allow est la directive de base qui permet d'autoriser une opération. Le premier paramètre est le domaine du processus qui sera autorisé à effectuer l'opération. Le second décrit l'objet qu'un processus du domaine aura le droit de manipuler. Ce paramètre prend la forme « type:genre » où type est son type SELinux et où genre décrit la nature de l'objet (fichier, répertoire, socket, fifo, etc.). Enfin, le dernier paramètre décrit les permissions (les opérations qui sont autorisées).
Permissions are defined as the set of allowed operations and follow this template: { operation1 operation2 } . However, you can also use macros representing the most useful permissions. The /usr/share/selinux/devel/include/support/obj_perm_sets.spt lists them.
La page web suivante fournit une liste relativement exhaustive des genres d'objet (object classes) et des permissions que l'on peut accorder :
|
avc: denied { read write } for pid=1876 comm="syslogd" name="xconsole" dev=tmpfs ino=5510 scontext=system_u:system_r:syslogd_t:s0 tcontext=system_u:object_r:device_t:s0 tclass=fifo_file permissive=1
Tableau 14.1. Analyse d'une trace SELinux
Message | Description |
---|---|
avc: denied | Une opération a été refusée. |
{ read write } | Cette opération requérait les permissions read et write . |
pid=1876 | Le processus ayant le PID 1876 a exécuté l'opération (ou essayé de l'exécuter). |
comm="syslogd" | Le processus était une instance de la commande syslogd . |
name="xconsole" | The target object was named xconsole . Sometimes you can also have a “path” variable — with the full path — instead. |
dev=tmpfs | The device hosting the target object is a tmpfs (an in-memory filesystem). For a real disk, you could see the partition hosting the object (for example: “sda3”). |
ino=5510 | L'objet est identifié par le numéro d'inode 5510. |
scontext=system_u:system_r:syslogd_t:s0 | C'est le contexte de sécurité courant du processus qui a exécuté l'opération. |
tcontext=system_u:object_r:device_t:s0 | C'est le contexte de sécurité de l'objet cible. |
tclass=fifo_file | L'objet cible est un fichier FIFO. |
allow syslogd_t device_t:fifo_file { read write }
. Ce processus est automatisable et c'est ce que propose la commande audit2allow
du paquet policycoreutils. Une telle démarche ne sera utile que si les objets impliqués sont déjà correctement étiquetés selon ce qu'il est souhaitable de cloisonner. Dans tous les cas, il faudra relire attentivement les règles pour les vérifier et les valider par rapport à votre connaissance de l'application. En effet, bien souvent cette démarche donnera des permissions plus larges que nécessaires. La bonne solution est souvent de créer de nouveaux types et d'attribuer des permissions sur ces types uniquement. Il arrive également qu'un échec sur une opération ne soit pas fatal à l'application, auquel cas il peut être préférable d'ajouter une règle dontaudit
qui supprime la génération de la trace malgré le refus effectif.
example.if
, example.fc
, and example.te
) match your expectations for the new rules, just run make NAME=devel
to generate a module in the example.pp
file (you can immediately load it with semodule -i example.pp
). If several modules are defined, make
will create all the corresponding .pp
files.