Slides

SELinux :
Security-Enhanced Linux
J. Briffaut
INSA CVL
STI
J. Briffaut Sécurité Système 1/72

Outline
1 Introduction
2 SELinux
3 Politique SELinux
4 Exemple de module SELinux
5 Administration
6 Intégration de SELinux
7 Bibliographie
Introduction
Sommaire
1 Introduction
2 SELinux
3 Politique SELinux
5 Administration
7 Bibliographie
Introduction Contrôle d’Accès
DAC : Contrôle d’Accès Discrétionnaire
DAC est le modèle utilisé classiquement sous UNIX

Les utilisateurs ont le contrôle complet des fichiers/programmes
leurs appartenant
création/modification/suppression
Les programmes lancées ont les même droits que l’utilisateur
Les utilisateurs peuvent donner des droits sur leurs ressources à
leur discrétion
chmod/chown
Le niveau de sécurité dépend du niveau de sécurité des
applications s’exécutant dessus
Si un programme s’exécutant sous root est compromis, l’attaquant

obtient les droits root et le système entier est compromis

Introduction Contrôle d’Accès
MAC : Contrôle d’Accès Mandataire

La sécurité d’un Systèmes d’exploitation est fondamental pour la
sécurité de chaque système informatique
Hypothèse fondamental pour garantir la sécurité :
Les applications ne peuvent pas apporter un niveau de sécurité
suffisant
Des applications sécurisées requièrent un système sécurisé
L’intégration de MAC améliore sensiblement la sécurité du
système
MAC protège l’information des utilisateurs légitimes ayant des
autorisations limitées ainsi que des utilisateurs autorisés ayant
exécutés, sans le vouloir, des applications malveillantes.
SELinux propose une architecture MAC forte et souple

Principe de Hardened Operating System

Introduction Généralité
SELinux ?
Security-Enhanced Linux :
Prototype de recherche développé par la NSA ...
... Mais intégré dans de nombreuses distributions
Partie Noyau + utilitaires
Contrôle d’Accès Mandataire (MAC)
RBAC : Role-based Access Control
TE : Type Enforcement
MLS/MCS : Sécurité multi-niveau/catégorie
Pas de concept de super-utilisateur (root)
Principe de SELinux
”The best practices for computer security includes the idea of least
privilege, meaning the absolute minimum amount of access is given
each user, process, or program to perform their required tasks.”
–Rick Larabee A Comparison of SELinux and LIDS

RBAC : Roles-Based Access Control

Implémenter un modèle MAC dans Unix est très difficile
Définir les règles d’accès pour tous les utilisateurs permettant
d’exécuter tous leurs programmes et d’accéder à tous leurs objets
Abouti à un énorme ensemble de règles
Avec RBAC, les administrateurs définissent
Des Rôles et autorisent certains Utilisateurs à accéder à ces Rôles
Les Rôles permettent d’accéder à des Objets avec différents Droits
User →use Role →right Object
RBAC permet de factoriser une politique MAC
Exemple
Un développeur Web doit pouvoir lire/écrire/modifier les fichiers
du type PHP
Un Administrateur Web doit pouvoir redémarrer le services
apache et lire les logs d’apache (uniquement !!!)
Un utilisateur quelconque doit pouvoir accéder aux pages PHP
Type-Enforcement
SELinux label chaque ressource du système avec un contexte de

sécurité (SC)
Contexte de sécurité sujet : processus
Contexte de sécurité objet : fichier, socket, périphérique, répertoire,
...
Le noyau contrôle (autorise/interdit) les accès entre deux SC
Module de sécurité (LSM) SELinux
SCsujet → SCsujet : contrôle entre processus (signaux, ...)
SCsujet → SCobjet : Contrôle d’accès aux ressources (lecture, ...)
Le noyau décide quels sujets peuvent accéder à quels ressources
Dans SELinux, ce contrôle est appelé Type Enforcement (TE)
Une politique SELinux fait au moins 200,000 lignes
Pour définir cette politique, il faut être un expert, les
administrateurs ne sont pas sensé la modifier.

SELinux
Sommaire
1 Introduction
2 SELinux
3 Politique SELinux
5 Administration
7 Bibliographie
SELinux SELinux ?
SELinux?
Implémentation d’un système de Contrôle d’Accès

Mandataire
Intervient après le Contrôle d’Accès Discrétionnaire de Linux
Mécanisme présent dans le noyau Linux (Security-¿SELinux)
Implantation sous forme de Linux Security Module (LSM)
Basé sur l’architecture Flask
Support flexible pour les politique de contrôle d’accès
Projet de longue date d’intégration d’une architecture de sécurité
dans un système d’exploitation (fluke)
Contrôle d’accès à fin grain (au niveau des appels système)
Projet développé par la NSA (National Security Agency)
Patch pour le noyau 2.4, intégré en standard dans le noyau 2.6

SELinux SELinux ?
A quoi sert SELinux?
On a un programme contenant une faille exploitable :

Localement : Buffer-Overflow sur les données saisies par le
programme (login, cron, ...), faille du type Local-¿Root
A distance : Buffer-Overflow sur les données traitées (apache,
bind, ...), faille du type Remote-¿Root
Le programme s’exécute avec les droits administrateur (root)
L’attaquant peut donc prendre tous les droits sur le système
en exploitant cette faille
Installer un rootkit, une backdoor, ...
Voler de l’information, modifier des fichiers, effacer le système
SELinux permet de vous prévenir de ce type d’attaque
SELinux n’empêche pas la vulnérabilité (i.e. le Buffer-Overflow,...)
Mais SELinux permet de limiter les dégâts en limitant les droits
associés au service
Ainsi l’attaquant obtient des droits administrateurs limités

SELinux Modèle
Elements de base
Contextes de sécurité : entité du système

Sujet (scs) : entité active du système (processus)
Objet (sco) : entité passive du système (fichier, sockets, ...)
Opération : une permission sur une classe

Classe : type de l’opération (file, dir, process, socket, ...)
Permission : droit de l’opération (read, write, unlink, accept, ...)
Interaction :
Une opération entre deux contextes de sécurité
i ::= scs1 →classe:permission sc2
Politique SELinux ::= Ensemble d’interactions légales

Le noyau contrôle ces interactions

SELinux Modèle
Contexte de Sécurité (1/3)

Ensemble d’attributs : attr1 : attr2 : attr3 : ...
Trois attributs de base :
identité : propriétaire du contexte
rôle : rôle du contexte (modèle RBAC)
rôle de l’identité pour les sujets
rôle par défaut pour les objets (object r )
type : type lié au modèle TE
Domaine pour un sujet (scs)
Type pour un objet (sco)
system u:system r:httpd t scs associe au processus apache

user u:user r : user t scs associe aux utilisateurs
system u:object r:apache exec t sco pour l ’ application apache (fichier )
D’autres attributs pour des extensions de SELinux (MultiLevel)

catégorie : modèle MCS (intégrité)
sensibilité : modèle MLS (confidentialité)
SELinux Modèle
Chaque processus du système est labellé par un CSS

Stocké dans la structure task de description d’un processus
Par défaut, lorsqu’un processus est créé (fork), il hérite du contexte
de son père
Un processus peut changer de contexte via une transition
Contexte de Sécurité Sujet

system u:system r:httpd t:[s0:c0.c24]
↕ ↕ ↕ ↕ ↘
Identité Rôle Domaine Sensibilité Catégorie

SELinux Modèle
Chaque objet du système est labellé par un CSO

Label stocké dans l’inode (attribut étendu)
Nécessite un système de fichier supportant xattrs
Un fichier spécial (file contexts permet de définir le contexte de
chaque objet du système
Par défaut, un fichier hérite du contexte de son répertoire père
Contexte de Sécurité Objet

system u:object r:http exec t:[s0:c0.c24]
↕ ↕ ↕ ↕ ↘
Identité Rôle(défaut) Type Sensibilité Catégorie

SELinux Modèle
Domaine et type (1/2)
Un type est un identifiant

Déclaré et défini par l’auteur d’une politique
Pas de signification intrinsèque : un type n’a de sens que par
l’utilisation qui en est faite dans la politique
Regroupe des sujets et objets ayant les mêmes autorisations
On parle de...
type pour un objet
domaine pour un sujet
... mais recouvrent les mêmes notions
Exemple : system t

SELinux Modèle
Domaine et type (2/2)

Domaines et types utilisés pour les décisions du type enforcement
Un sujet d’un domaine d peut effectuer une opération o sur un
objet de type t seulement si la politique DTE l’autorise
Convention de nommage pour une application/service appli:
applid t : Domaine (associé a un processus service)
appli t : Domaine (associé a un processus classique)
appli exec t : application (le fichier)
appli conf t : fichier de configuration
appli log t : fichier de log
appli file t : fichier divers
appli lib t : librairie
appli tmp t : fichier temporaire
Un objet/processus possède un et un seul type

Mais un même type peut être associé à plusieurs objets
=> Permet de factoriser la politique
SELinux Modèle
SELinux = RBAC & DTE
Identity

SELinux Modèle
Identity Role

SELinux Modèle
Identity Role Domain

SELinux Modèle
Identity Role Domain Type

SELinux Modèle
httpd_exec_t
httpd_t
system_u system_r httpd_config_t
httpd_php_t
httpd_php_exec_t

SELinux Modèle
httpd_exec_t
httpd_t
httpd_php_t
Subjects httpd_php_exec_t

SELinux Modèle
httpd_exec_t
httpd_t
httpd_php_t
Subjects httpd_php_exec_t
Objects

SELinux Modèle
Opération
Opération = droit d’un Contexte sujet sur un autre contexte
Un droit est une permission autorisée sur une classe d’objet
Droit ::= classe : permission
Classe
Les objets du système sont diviser en classe :
file, dir, socket, process, ...
self : classe spécifique identifiant le processus lui-même
Permission
Chaque classe propose un ensemble de permissions :
appels système :read, write, execute, link, open, ...
transition : permission spécifique permettant de changer de contexte
(identité, role, ou domaine)
SELinux comprends >50 classes, >200 permissions
SELinux permet un contrôle d’accès fin (de l’ordre de l’appel système)

SELinux Modèle
Opération de transition (1/3)
Par défaut, lorsqu’un processus est créé, il hérite du contexte de

son père
Un processus peut modifier un attribut de son contexte, i.e.
transiter
Chaque attribut à des règles spécifiques :
Identité : Impossible à changer normalement (sauf appel à setcon()
Rôle : L’identité peut utiliser le rôle (règle allow)
Type : L’opération process:transition est définit entre les deux types
Une transition n’est possible que si elle est autoriser par la
politique
Les transitions permettent de confiner les

services/applications/utilisateurs dans leurs domaines respectifs

SELinux Modèle
Opération d’affectation d’un type

par défaut à la création
d’un sujet (transition de domaine), via execve()
d’un objet (création d’un fichier, ouverture de socket, etc.)
spécifique, à la demande d’un processus “SELinux-aware”, pour
l’exécution d’une opération privilégiée
Dans les deux cas, la politique doit autoriser la transition

explicitement
La spécification d’un type par défaut n’est pas une autorisation
La politique doit en plus autoriser la transition de type

SELinux Modèle
Une transition peut être :

Automatique :
Lorsqu’un processus exécute un fichier, le processus résultant
transite automatiquement (par exemple init t →process:transition sshd t
lors de l’accès à /usr/bin/sshd)
Lorsqu’un processus crée un objet dans un répertoire, l’objet peut
prendre un type spécifique au lieu d’hériter du type du répertoire père
(par exemple, le fichier créé par httpd t dans /tmp/ sont typé
automatiquement par ssh tmp t au lieu de tmp t)
Manuelle :
appel à la fonction SELinux setcon(sid id) dans le code du
programme (nécessite le droit de transiter dynamiquement vers le
contexte cible : scsource →process:dyntransition sccible

SELinux Politique de sécurité
Politique SELinux
Définie l’ensemble des règles de contrôle d’accès
Éléments constitutifs
Déclarations et définition des Identités, Roles, Types
Définition des règles d’autorisation d’accès
Définition des règles de transitions de types
Définition des règles d’audit (accounting)
Expression de la politique dans un langage dédié

Sémantique bien définie
Vérification automatique possible (contrainte)
Utilisation de macros (factorisation de code)

Format de politique SELinux
Il existe deux versions de politiques SELinux

Statique
Une politique est un fichier binaire monolithique
La modification d’une règle nécessite la recompilation de toute la
politique
Ancien système de gestion de politique SELinux
Modulaire
Une politique est une collection de modules
Chaque module spécifie la politique propre à une application
apache, mozilla, login, ssh, etc.
Une modification de la politique ne nécessite plus la recompilation
de l’ensemble de la politique
Dynamique
Insertion et retrait de modules “à chaud”
Ajout d’1 module lors de l’ajout d’une application

Type de politique SELinux
2 types de politiques sont disponibles

targeted
Protection des services système (apache, ssh, etc.)
Le reste du système est “unconfined” (aucun contrôle)
Suffisant contre les attaques sur les services administrateurs
Par défaut sur les systèmes RedHat
strict
Protection de l’ensemble du système
Services et applications Système/Utilisateur
Beaucoup plus contraignante
Pour chaque type, il existe 2 options supplémentaires

mls : Politique multi-niveaux
mcs : Politique multi-catégorie

Mode de politique SELinux
Il existe 2 modes d’application disponibles
Permissive
Décisions seulement loggées par le noyau (denied/granted)
Déboguage de politiques
Fonctionnement en mode IDS
Enforced
Décisions appliquées sur le système
Peut engendrer des dis-fonctionnements applicatifs si
La politique est mal conçue (comportement légitime de l’application)
L’application est mal conçue (comportement litigieux privilèges
excessifs)

Politique SELinux
Sommaire
1 Introduction
2 SELinux
3 Politique SELinux
5 Administration
7 Bibliographie
Politique SELinux
Spécification d’une politique SELinux
La spécification d’une politique SELinux nécessite la définition de

La liste des identités
Indépendant des utilisateurs système
Affectation des utilisateurs systèmes aux entités
La liste des rôles
L’affection des identités aux rôles
La liste des types
Affection des types accessibles aux rôles
Les règles de contrôles d’accès
Droits (opérations légales) d’un type sur un autre
Les règles de transitions
Le lien entre les objets système (fichier ...) et les contextes objet
Les règles d’audit : opération légale mais génère une trace
Les contraintes : vérification basique de la politique

Politique SELinux Identités
Identités
Indépendantes des identités système (UID)

Les deux subsistent sur le système
Persistance des identités SELinux
Un sujet conserve son identité tout au long de sa session (même
après un su)
Exception à la règle :
Processus d’authentification (login, gdm, ssh, etc.)
- Pour l’affectation de l’identité initiale d’un utilisateur
cron
- Pour l’exécution automatique de processus sous une identité donnée
Permet l’imputabilité des actions sur le système

Fichiers de configuration
Associer un utilisateur à une identité SELinux

association utilisateur:identité
utilisateur system u spécifique à SELinux (aucun utilisateur réel)
pour les services systèmes
Identitéuser u par défaut ( default ) pour les utilisateurs
non-déclarés dans la politique
config/appconfig-*/seusers
system u:system u
root : root
default :user u

Fichiers de configuration
Créer une identité SELinux pour un utilisateur spécifique
config/local.users
##################################
#
# User configuration.
#
# This file defines additional users recognized by the system security policy .
# Only the user identities defined in this file and the system.users file
# may be used as the user attribute in a security context.
#
# Each user has a set of roles that may be entered by processes
# with the users identity . The syntax of a user declaration is :
#
# user username roles role set [ level default level range allowed range ];
# sample for administrative user

user briffaut roles { staff r sysadm r };
# sample for regular user

user toto roles { user r };

Politique SELinux Rôles
Rôles
Les rôles relient les utilisateurs aux domaines (types SC sujets)

Chaque identité peut accéder à une liste de rôles ...
... et donc accéder à un ensemble de domaines
Application de contraintes supplémentaires
L’affectation d’un type à un processus est permise ssi une définition
de rôle l’autorise dans la politique
Même si permis par DTE
Interviennent dans les transitions de domaines
Un utilisateur peut changer de rôle au cours d’une session
Commande newrole
La notion de rôle ne s’applique qu’aux SC sujets (processus)

Configuration
Déclaration des rôles (policy/users)
# Declarations
role sysadm r;
role staff r ;
role user r ;
Association des rôles à une identité

# l ’ utilisateur root peut utiliser les r ôles user r et sysadm r
user root roles {user r sysadm r};
Association des types à un rôle

# le r ôle sysadm r peut accéder au type sysadm t
role sysadm r types sysadm t;
role staff r types staff gpg t ;
Transition autorisé d’un role vers un autre

# le role system r peut transiter vers le r ôle sysadm r
allow system r sysadm r;
allow staff r sysadm r;
Comparaison RBAC / SELinux
RBAC
Affectation d’autorisations à des rôles
Autorisation des utilisateur à assumer un ou plusieurs rôles
SELinux
Affectation d’autorisations entre des domaines et des types
Affectation de domaines à des rôles
Autorisation des utilisateurs à assumer un ou plusieurs rôles

Politique SELinux Règles de contrôle d’accès
Règles d’autorisation
Déclaration des éléments de base :

Un ensemble de classe
Un ensemble de permissions pour chaque classes
Couple classe:permissions =¿ opération à contrôler
Déclaration d’un ensemble de Type
Type sujets (domaines) et Type objets
Contrôle les opérations entre deux types
1 domaine : type associé à un sujet (processus)
1 type : sujet ou objet
Plusieurs contrôles possibles :
allow: autorisé
neverallow: interdit
auditallow: audit de l’autorisation
neveraudit: ne jamais auditer

Configuration : Elements de base

Déclaration des classes (policy/flask/security classes)
class security
class process
class system
Déclaration des permissions

(policy/flask/access vectors)
common file
{
ioctl
read
write
[...]
}
class file
inherits file
{
execute no trans
entrypoint
[...]
Configuration : Déclaration des types I
Déclaration des types

Tous les types (sujets, objets) doivent être déclarés 1 seul fois
avant leur utilisation
# déclaration d’un type seul
# sujet
type init t ;
type sshd t;
#objet
type init conf t ;
type sshd exec t;
type admin passwd exec t;

Configuration : Déclaration des types II

Utilisation d’attribut pour catégoriser les types
1 attribut ::= 1 ensemble de types
1 attribut est vu comme un type
Définition d’attributs
attribute admin terminal;
attribute application domain type;
# Permet de regrouper tous les types correspondant aux applications executables
attribute application exec type;
Déclaration des types et association aux attributs

# association d’un type (déjà déclaré) à un attribut
typeattribute shadow t security file type ;
typeattribute local login t can read shadow passwords;
# déclaration d’un type et association à des attributs

type afs bos client packet t , packet type, client packet type ;
type accelgraphics xext t , xextension type;

Configuration : Règles de contrôle d’accès I
Règle d’autorisation :
allow typesource typecible :class { permissions} ;
# le sujet avec le type sysadm t peut exécuter (...) les fichiers avec le type
ssh exec t
allow sysadm t ssh exec t: file { getattr read execute };
# le sujet avec le type sysadm t peut exécuter (...) les fichiers avec le type ayant
comme attribut application exec type
allow sysadm t application exec type: file { getattr read execute ioctl lock
execute no trans };

Configuration : Règles de contrôle d’accès II
Autres règles de contrôle

# On audite l ’ accès en lecture au type shadow t par sysadm t
auditallow sysadm t file:read shadow t;
# Les types non−privil égié ne peut pas lire shadow t
# Utilisation de ˜ pour la négation
neverallow ˜can read shadow passwords shadow t:file read;
# Ne pas auditer certains accès aux répertoires pour le type staff t
# utilisation de − pour retirer le type security file type de file type
dontaudit staff t { file type − security file type }: dir { getattr search read lock};

Factorisation des permissions
Macros de permissions : policy/support/*perms set.spt

Exemples :
r file perms : permissions pour lire un fichier
open, getattr, read, lock, ioctl
r dir perms : permissions pour traverser un répertoire
open getattr read lock search ioctl
x file perms : permissions pou exécuter un fichier
open getattr execute

Politique SELinux Règles de transitions
Transition de type I
Transition de type automatique lors d’un accès (sujet)

Permet de raffiner/spécifier/changer les droits d’un nouveau
programme en fonction de son but
Confine un processus dans son domaine
# Lorsque le type user t cr ée exécute le fichier ayant le type ssh exec t il transite
automatiquement vers user ssh t
type transition user t ssh exec t:process user ssh t;
# Lorsque le type user t cr ée exécute le fichier ayant le type passwd exec t il transite
automatiquement vers passwd t
type transition user t passwd exec t:process passwd t;
Nécessite des règles allow supplémentaire

allow user t ssh exec t : file {read getattr execute}
allow user ssh t ssh exec t : file entrypoint ;
allow user r user ssh t : process transition ;

Politique SELinux Règles de transitions
Transition de type II
Transition de type automatique lors d’un accès (objet)

Permet de changer automatiquement le type des objets créés
# Lorsque le processus labellé par user t accède àun fichier (...) de type tmp t, le
type de cet objet transite automatiquement vers user tmp t
type transition user t tmp t:{ dir file lnk file sock file fifo file } user tmp t;
# Lorsque le processus labellé par sshd t accède àun fichier (...) de type tmp t, le
type de cet objet transite automatiquement vers sshd tmp t
type transition sshd t tmp t:{ dir file sock file } sshd tmp t;
Nécessite des règles allow supplémentaire

allow user t tmp t: dir { open getattr create write };
allow user t user tmp t: file rw file perms;

Politique SELinux Contextes de sécurité
Attribution des contextes I
Sujets : les contextes sont créés dynamiquement

Hérité du processus père (init est le père de tous les processus)
Modifié par transition (dynamique ou manuelle)
Exemple
Lorsque init (system u:system r:init t) lance le service ssh, le
processus ssh transite automatiquement vers system u:system r:sshd t

Attribution des contextes II
Objets : des règles permettent de faire le liens entre l’objet

(fichier, répertoire, ...) et le contexte objets
Après compilation de la politique, on obtient un fichier
file contexts qui permet de relabeller le système
le label (contexte) des objets est stocké dans l’inode sous forme
d’attribut étendu
lorsqu’un nouvel objet est créé, il hérite du contexte de son
répertoire père
son contexte peut être changer via une règle type transition

Attribution des contextes objets

Règles d’association
#HOME DIR est une variable qui représente tous les home directory
HOME DIR/\.ssh(/.*)? system u:object r:ROLE home ssh t
#label les fichiers sensibles

/etc/ssh/primes −− system u:object r:sshd key t
/etc/ssh/ssh host key −− system u:object r:sshd key t
/etc/ssh/ssh host dsa key −− system u:object r:sshd key t
/etc/ssh/ssh host rsa key −− system u:object r:sshd key t
#label les applications

/usr/bin/ssh −− system u:object r:ssh exec t
/usr/bin/ssh−agent −− system u:object r:ssh agent exec t
/usr/bin/ssh−keygen −− system u:object r:ssh keygen exec t
/usr/ libexec /openssh/ssh−keysign −− system u:object r:ssh keysign exec t
#label le service
/usr/sbin/sshd −− system u:object r:sshd exec t
#label les fichiers variables cr éé par le daemon

/var/run/sshd\. init \.pid −− system u:object r:sshd var run t
Politique SELinux Contraintes
Contraintes sur les règles

Expressions booléennes exprimées dans la politique
Vérifié lors de la compilation de la politique
Opérateurs logiques =, !=, and, or
Contraintes basées sur les identités, rôles et types
Utilisation des attributs pour les vérifications
#contrainte sur la transition de processus
constrain process transition
(
# l ’ identit é source et cible doivent être identique
u1 = u2
# le type doit avoir le droit de changer l’ identit é ( login ...)
or ( t1 = can change process identity and t2 = process user target )
# il s’ agit de cron
or ( t1= cron source domain and (t2= cron job domain or u2= system u))
# il s’ agit du systeme
or ( t1 = can system change and u2 = system u )
# aucun contrôle sur ce type
or ( t1 = process uncond exempt )
);

Exemple de module SELinux
Sommaire
1 Introduction
2 SELinux
3 Politique SELinux
5 Administration
7 Bibliographie
Exemple de module SELinux Ecriture d’une politique SELinux
Architecture d’un module
Un module est un sous-partie de la politique SELinux pour un

service/application
Un module peut-être chargé/déchargé du noyau
Un module, pour une application myapps, est constitué de 3
fichiers
myapps.te : déclaration des règles du modèle TE
Nom du module et version
Déclaration des rôles, types sujets et objets
Déclaration des règles de contrôle
myapps.fc : déclaration des contextes objets
Déclaration des associations fichier¡-¿contexte objet
myapps.if : déclaration des règles pour les autres modules
Règles dynamique pour l’interaction avec les autres modules
Règles génériques : utilisation de macros et de variables
Makefile générique pour la compilation/chargement du module

Exemple de module SELinux Écriture d’un module (1/4)
Fichier de déclaration des règles TE (1/2)

Exemple de module dans /usr/share/doc/selinux*/
Module pour une application myapps
Fichier example.te (début)
# Nom du module et version
policy module(myapp,1.0.0)
# Declarations des types
type myapp t;
type myapp exec t;
# association de myapp t à l ’ attribut domaine (contexte sujet)
domain type(myapp t)
# transition automatique vers myapp t lors de l ’ exécution de myapp exec t
domain entry file (myapp t, myapp exec t)
# type pour les fichiers de logs
type myapp log t;
# ajout de myapp log t à l ’ attribut log file
logging log file (myapp log t)
# déclaration du type pour les fichiers temporaires
type myapp tmp t;
# ajout de myapp t à l ’ attribut tmp file
files tmp file (myapp tmp t)

Fichier de déclaration des règles TE (2/2)

Fichier example.te (fin)
Déclaration des règles de contrôles
########################################
#
# Myapp local policy
#
# myapp peut lire/ ajouter dans les fichiers myapp log t

# utilisation d’un attribut pour les permissions : ra file perms (read/append)
allow myapp t myapp log t:file ra file perms ;
# génération des règles d’accès pour myapp t àmyapp log t

# myapp t peut changer les droits sur ces fichiers temporaires myapp tmp t
# utilisation d’un attribut manage file perms pour les opérations de changement de
droits
allow myapp t myapp tmp t:file manage file perms;
# transition automatique pour les fichiers cr éés tmp t vers myapp tmp t
files tmp filetrans (myapp t,myapp tmp t,file)

Fichier de déclaration des contextes
Fichier example.fc
Association des objets système aux contextes
# myapp executable will have:

# label : system u:object r:myapp exec t
/usr/sbin/myapp −− system u:object r:myapp exec t

Fichier de déclaration des interfaces

Fichier example.if
########################################
## <summary>
## Execute a domain transition to run myapp.
## </summary>
## <param name←”domain”>
## Domain allowed to transition .
## </param>
# Règles pour la transition automatique d’un type ($1) vers myapp t
interface (‘ myapp domtrans’,‘
gen require(‘
type myapp t, myapp exec t;
’)
domain auto trans($1,myapp exec t,myapp t)
allow $1 myapp t:fd use;

allow myapp t $1:fd use;
allow $1 myapp t: fifo file rw file perms;
allow $1 myapp t:process sigchld;
’)

Exemple de module SELinux Compilation/Chargement/Installation
Compilation et chargement du module

Fichier Makefile
Permet de compiler le module
Commande make
Vérifie que tout est bien déclaré, vérifie les contraintes et compile
Après compilation on obtient un fichier .pp (e.g. example.pp)
Permet de chargé la politique
Commande make load
La politique est immédiatement appliqué
machine1 piga # make
Compiling strict piga module
/usr/bin/checkmodule: loading policy configuration from tmp/piga.tmp
/usr/bin/checkmodule: policy configuration loaded
/usr/bin/checkmodule: writing binary representation (version 6) to tmp/piga.mod
Creating strict piga.pp policy package
rm tmp/piga.mod.fc tmp/piga.mod
machine1 piga # make load

Loading strict modules: piga

Exemple de module SELinux Compilation/Chargement/Installation
Attribution des contextes objets au système

Pour tout le système
machine1 piga # rlpkg
Usage: rlpkg [OPTIONS] {<pkg1> [<pkg2> ...]}
−a, −−all Relabel the entire filesystem instead of individual packages.
−r, −−reset Force reset of context if the file ’ s selinux identity is
different or the file ’ s type is customizable.
−t , −−textrels Scan for libraries with text relocations and relabel them.
machine1 piga # rlpkg −ar
Relabeling filesystem types: ext2 ext3 jfs xfs
/usr/sbin/ setfiles : labeling files under /
matchpathcon filespec eval: hash table stats : 289770 elements, 63403/65536 buckets
Pour un module qui vient d’être compilé

machine1 piga # setfiles
usage: setfiles [−dnpqvW] [−o filename] [−r alt root path ] spec file pathname...
usage: setfiles −c policyfile spec file
usage: setfiles −s [−dnqvW] [−o filename ] spec file
machine1 piga # setfiles piga.fc /
setfiles : labeling files under /
matchpathcon filespec eval: hash table stats : 7 elements, 7/65536 buckets used,
longest chain length 1
setfiles : Done. J. Briffaut Sécurité Système 55/72
Exemple de module SELinux Analyse
Outils d’aide à l’écriture de politique

Trace d’exécution
Fichier /var/log/avc.log
dmesg
type←1400 audit(1227463900.474:15869): avc: granted { read execute } for pid←10488
comm←”dmesg” ppid←8900 path←”/lib/libc−2.6.1.so” dev←sda3 ino←788736
scontext←root:sysadm r:sysadm t tcontext←system u:object r:lib t tclass←file
Conception de politique
polgen (Mitre) : induction de politiques à partir de traces
d’exécution d’un programme
sediff : différences sémantiques entre politiques
sechecker : recherche d’erreurs dans une politique
Analyse de trace (aide au diagnostic)
seaudit : audit2why (motif des refus d’accès), audit2allow (aide à
la résolution de problèmes)

Exemple de audit2allow
Trace d’exécution illégale
type=PATH msg=audit(1176369121.794:1514): item=0 na
type=CWD msg=audit(1176369121.794:1514): cwd="/" t
13 a0=bfe58b40 a1=80c2 a2=18 a3=180 items=1 ppid=14
type=AVC msg=audit(1176369121.794:1514): avc: deni
Déduction des règles
[style=selinux,keywords={machine1},ndkeywords={audi
# audit2allow -i /var/log/audit/audit.log
allow prelink_t usr_t:dir add_name;
# audit2allow -R -i /var/log/audit/audit.log
require {
type prelink_t;
}
files_rw_usr_dirs(prelink_t)

Exemple de audit2allow
création automatique d’un module pour myprelink

[style=selinux,keywords={machine1},ndkeywords={audi
# audit2allow -M myprelink -R -i /var/log/audit/aud
******************** IMPORTANT ********************
To make this policy package active, execute:
semodule i myprelink.pp
# ls myprelink*
myprelink.fc myprelink.if myprelink.pp myprelink

Administration
Sommaire
1 Introduction
2 SELinux
3 Politique SELinux
5 Administration
7 Bibliographie
Administration Installation d’une politique
Installation de SELinux
Intégré par défaut sous Redhat

Choix du type (strict, targeted), de la catégorie (mls, mcs) et du
mode (permissive, enforcing) lors de l’installation
Autre distribution :
Activer SELinux dans le noyau (Security->SELinux
Installation des outils “userland”
checkpolicy, policycoreutils, libselinux
Installation d’une politique
Source de la politique : selinux-base-policy
Choix de la politique dans /etc/selinux/config

Configuration du noyau
Option du noyau
Under ”Security options”
[*] Enable different security models
[*] Socket and Networking Security Hooks
<*> Default Linux Capabilities
[*] NSA SELinux Support
[ ] NSA SELinux boot parameter
[ ] NSA SELinux runtime disable
[*] NSA SELinux Development Support
[ ] NSA SELinux AVC Statistics
(1) NSA SELinux checkreqprot default value
[ ] NSA SELinux enable new secmark network controls by default
[ ] NSA SELinux maximum supported policy format version

Choix de la politique
/etc/selinux/config contents
# This file controls the state of SELinux on the system on boot.
# SELINUX can take one of these three values:

# enforcing − SELinux security policy is enforced.
# permissive − SELinux prints warnings instead of enforcing.
# disabled − No SELinux policy is loaded.
SELINUX←enforcing
# SELINUXTYPE can take one of these two values:

# targeted − Only targeted network daemons are protected.
# strict − Full SELinux protection.
SELINUXTYPE←strict

Application des patchs pour les outils système
Intégration de SELinux dans certains outils
* app-admin/logrotate
* sys-apps/fcron
* sys-apps/vixie-cron
* sys-fs/device-mapper
* sys-fs/udev
* sys-libs/pwdb

Administration Commandes basiques
Lister les contextes de sécurité

Contextes objets
#ls −Z /
drwxr−xr−x root root 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
Contextes sujets
#ps ax −Z
PID CONTEXT COMMAND
1 system u:system r: init t [ init ]
2 system u:system r:kernel t [keventd]
3 system u:system r:kernel t [ksoftirqd CPU0]
4 system u:system r:kernel t [kswapd]
6 system u:system r:kernel t [kupdated]
706 system u:system r:syslogd t [syslog−ng]
712 system u:system r:httpd t [apache]

Administration Commandes d’administration
Commande basique
Chargé la politique dans le noyau
# semodule −B
Changer de rôle
# newrole −r sysadm r
Spécifier les rôles possibles pour un utilisateur

# semanage login −a −s staff u briffaut
Relabeller le système
# rlpkg −a
Relabeller un packet
# rlpkg ssh

Commande basique
Passer du mode enforcing au mode permissif

Query current mode
# cat / selinux /enforce
Switch to enforcing mode
# echo 1 > /selinux/enforce
Switch to permissive mode
# echo 0 > /selinux/enforce
Statut courrant de la politique

#sestatus
SELinux status: enabled
SELinuxfs mount: / selinux
Current mode: enforcing
Policy version: 18

Commande basique
Management de la politique
machine1 ˜ # semanage
semanage {login|user|port|interface|fcontext| translation } −l [−n]
semanage login −{a|d|m} [−sr] login name
semanage user −{a|d|m} [−LrRP] selinux name
semanage port −{a|d|m} [−tr] [ −p protocol ] port | port range
semanage interface −{a|d|m} [−tr] interface spec
semanage fcontext −{a|d|m} [−frst] file spec
semanage translation −{a|d|m} [−T] level

Intégration de SELinux
Sommaire
1 Introduction
2 SELinux
3 Politique SELinux
5 Administration
7 Bibliographie
Intégration de SELinux Modification système
NSA SELinux : modifications système
SELinux nécessite des applications modifiées RBAC+TE

Beaucoup d’outils (passwd, useradd, groupadd) ont été modifié
Psmisc procps Util −linux

Passwd Shadow−utils tar
rmt Openssh Vixie−cron
Strace Stat Kernel
SELinux ne supportent pas encore le serveur X

Nécessite de capturer tous les événements X
Nécessite de labellé le système
Stocker le contexte de sécurité en dur dans l’inode des objets
Nécessite une politique pour chaque application
Concept de 1 domaine spécifique pour 1 application

Intégration de SELinux Modification système
NSA SELinux : modifications noyau
SELinux modifie un grand nombre d’appels systèmes :

accept,connect,execve,fstat, fstatfs , ...
SELinux ajoute de nombreux nouveaux appels système sécurisé

Chsidfs,fchsid , fchsidfs ,getosecsid
NAME
accept, accept secure accept a connection on a socket
SYNOPSIS
#include <sys/types.h>
#include <sys/socket.h>
int accept(int s, struct sockaddr *addr, int * addrlen);
int accept secure(int s, struct sockaddr *addr, int * addrlen, security id t
* sid) ;

Bibliographie
Sommaire
1 Introduction
2 SELinux
3 Politique SELinux
5 Administration
7 Bibliographie
Bibliographie
Liens utiles
http://www.nsa.gov/selinux/
http://fedora.redhat.com/projects/selinux/
http://selinux-symposium.org/
http://www.tresys.com/

Slides

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Slides

Transféré par

Droits d'auteur :

Formats disponibles

SELinux :

J. Briffaut Sécurité Système 1/72

4 Exemple de module SELinux

4 Exemple de module SELinux

DAC : Contrôle d’Accès Discrétionnaire

DAC est le modèle utilisé classiquement sous UNIX

Si un programme s’exécutant sous root est compromis, l’attaquant

J. Briffaut Sécurité Système 4/72

MAC : Contrôle d’Accès Mandataire

SELinux propose une architecture MAC forte et souple

J. Briffaut Sécurité Système 5/72

J. Briffaut Sécurité Système 6/72

RBAC : Roles-Based Access Control

SELinux label chaque ressource du système avec un contexte de

J. Briffaut Sécurité Système 8/72

4 Exemple de module SELinux

Implémentation d’un système de Contrôle d’Accès

J. Briffaut Sécurité Système 10/72

A quoi sert SELinux?

On a un programme contenant une faille exploitable :

J. Briffaut Sécurité Système 11/72

Contextes de sécurité : entité du système

Opération : une permission sur une classe

Politique SELinux ::= Ensemble d’interactions légales

J. Briffaut Sécurité Système 12/72

Contexte de Sécurité (1/3)

system u:system r:httpd t scs associe au processus apache

D’autres attributs pour des extensions de SELinux (MultiLevel)

Contexte de Sécurité (2/3)

Chaque processus du système est labellé par un CSS

Contexte de Sécurité Sujet

J. Briffaut Sécurité Système 14/72

Contexte de Sécurité (3/3)

Chaque objet du système est labellé par un CSO

Contexte de Sécurité Objet

J. Briffaut Sécurité Système 15/72

Domaine et type (1/2)

Un type est un identifiant

J. Briffaut Sécurité Système 16/72

Domaine et type (2/2)

Un objet/processus possède un et un seul type

SELinux = RBAC & DTE

J. Briffaut Sécurité Système 18/72

SELinux = RBAC & DTE

J. Briffaut Sécurité Système 18/72

SELinux = RBAC & DTE

Identity Role Domain

J. Briffaut Sécurité Système 18/72

SELinux = RBAC & DTE

Identity Role Domain Type

J. Briffaut Sécurité Système 18/72

SELinux = RBAC & DTE

Identity Role Domain Type

system_u system_r httpd_config_t

J. Briffaut Sécurité Système 18/72

SELinux = RBAC & DTE

Identity Role Domain Type

system_u system_r httpd_config_t

J. Briffaut Sécurité Système 18/72

SELinux = RBAC & DTE

Identity Role Domain Type

system_u system_r httpd_config_t

J. Briffaut Sécurité Système 18/72

SELinux permet un contrôle d’accès fin (de l’ordre de l’appel système)