Lorsqu'un processus effectue une opération sur un fichier, le noyau Linux effectue la vérification dans l'ordre suivant :
-
Contrôle d'accès discrétionnaire (DAC) ou contrôle d'accès dicté par l'utilisateur. Cela inclut à la fois les contrôles d'autorisation de style UNIX classique et les listes de contrôle d'accès (ACL) POSIX. Les vérifications UNIX classiques comparent l'UID et le GID du processus actuel avec l'UID et le GID du fichier auquel on accède en fonction des modes qui ont été définis (lecture/écriture/eXecute). La liste de contrôle d'accès étend les vérifications UNIX classiques pour permettre plus d'options concernant le contrôle des autorisations.
-
Contrôle d'accès obligatoire (MAC) ou contrôle d'accès basé sur des politiques. Ceci est implémenté à l'aide de modules de sécurité Linux (LSM) qui ne sont plus de vrais modules (ils l'étaient auparavant mais ils ont été abandonnés). Ils permettent des contrôles supplémentaires basés sur d'autres modèles que les contrôles de sécurité classiques de type UNIX. Tous ces modèles sont basés sur une politique décrivant quel type d'opérations sont autorisées pour quel processus et dans quel contexte.
Voici un exemple d'accès aux inodes (qui inclut l'accès aux fichiers) pour étayer ma réponse avec des liens vers une référence croisée Linux en ligne. Le "function_name (filename:line)" donnés sont pour la version 3.14 du noyau Linux.
La fonction inode_permission (fs/namei.c:449) vérifie d'abord l'autorisation de lecture sur le système de fichiers lui-même (sb_permission dans fs/namei.c:425), puis appelle __inode_permission (fs/namei.c:394) pour vérifier les autorisations de lecture/écriture/exécution et l'ACL POSIX sur un inode dans do_inode_permission (fs/namei.c:368) (DAC) puis les autorisations liées au LSM (MAC) dans security_inode_permission (security/security.c:550).
Il n'y en avait qu'un exception à cet ordre (DAC puis MAC) :c'était pour les vérifications mmap. Mais cela a été corrigé dans la version 3.15 du noyau Linux (commit pertinent).
DAC ==Discretionary Access Control , http://en.wikipedia.org/wiki/Discretionary_access_control
MAC ==Mandatory Access Control , http://en.wikipedia.org/wiki/Mandatory_access_control
ACL ==Access Control List , http://en.wikipedia.org/wiki/Access_control_list
Le ACL précise les contrôles à appliquer par la méthode de contrôle, DAC ou MAC . MAC est explicite, contrôlé de manière centralisée et ne permet pas aux utilisateurs d'accorder l'autorité à un objet à moins qu'ils n'aient des autorisations explicites pour le faire, alors que DAC permet aux utilisateurs d'accorder à d'autres utilisateurs l'accès aux objets auxquels ils peuvent accéder.
MAC ACL s sera toujours appliqué à une demande en premier, et si l'accès est refusé, le traitement s'arrête. Si l'accès est autorisé, alors le DAC ACL s sont appliqués, et de nouveau si l'accès est refusé, le traitement s'arrête. Uniquement si l'accès est accordé par les deux MAC et DAC ACL s l'utilisateur peut-il accéder à l'objet qu'il a demandé.
SELinux est un MAC implémentation pour Linux (il y en a d'autres), tandis que le traditionnel rwx les autorisations de fichier, combinées avec l'utilisateur propriétaire et le groupe forment le DAC complet ACL . Le SELinux 'policy' est essentiellement le MAC ACL .
Désolé d'ergoter, mais je pense que certaines des réponses ici pourraient être incorrect. Directement depuis le http://docs.fedoraproject.org/en-US/Fedora/13/html/Security-Enhanced_Linux/sect-Security-Enhanced_Linux-Working_with_SELinux-SELinux_Contexts_Labeling_Files.html de Fedora :
Les règles de politique SELinux sont vérifiées après les règles DAC. Les règles de politique SELinux ne sont pas utilisées si les règles DAC refusent l'accès en premier.