Selinux

Personal tools 

Log in

Views 

Article



Discussion



View source



History

Fr FR/SELinux/ContexteSecurite

WIKI

Main Page News

From FedoraProject < Fr FR | SELinux

Events Features

Contents

Recent changes



1 Contexte de Sécurité

Random page



Help



NAVIGATION

Home Get Fedora Join Fedora SUB-PROJECTS

Ambassadors Artwork Bug Zappers Documentation Infrastructure Internationalization Localization Marketing Package Maintainers Websites Weekly News All projects SEARCH

1.1 system_u:object_r:httpd_exec_t:s0 1.2 4ème partie: Partie MLS



1.3 3ème partie: Types 1.4 2nde partie: Rôles



1.5 1ère partie: Utilisateurs



Contexte de Sécurité system_u:object_r:httpd_exec_t:s0 Tout dans SELinux tourne autour du Label de Sécurité, ou du Contexte de Sécurité. Tout Sujet  (processus) et Objet (habituellement les fichiers de l’ordinateur) possède un contexte de  sécurité qui lui est associé. Ce contexte à différent nom suivant à quoi il est attaché. Il est  appelé file_context quand il est associé à un fichier. Et il est quelquefois appelé Domaine  lorsque associé à un processus. Le contexte du fichier est stocké avec l’Inode dans un attribut étendu sur les systèmes (de  fichier) supportant les attributs étendus. Cela fonctionne de la même manière que les DAC  (explication ??!) et les ACLs (Access Control List/Liste de Contrôle d’Accès). En cela, la sécurité  du fichier est basée sur les informations stockées dans l’Inode et non dans le chemin d’accès au  fichier.  Sur les systèmes de fichiers qui ne supportent pas les attributs étendus, le noyau fournis les  contextes de fichier. Par exemple, il existe une règle sur les systèmes SELinux qui précise que  tous les fichiers situés sur un volume NFS monté seront labélisés system_u:object_r:nfs_t Maintenant, regardons ce qui forme un contexte de sécurité. 

Go  

Search

TOOLBOX

What links here Related changes

Un contexte de sécurité est formé de 3 ou 4 parties séparés par ":" Je vais décrire ces  composants en commençant du dernier vers le premier. 

4ème partie: Partie MLS La quatrième partie est le champ MLS qui n'est pas supporté dans RHEL 4 ou Fedora Core 4.  On peut l'apercevoir en à partir de Fedora Core 5, toutefois, il existait dans les versions  précédentes de SELinux mais n'avais jamais été activé.  Cette composante est utilisée par toutes les politiques chargées avec Fedora Core 5. Avec les  politiques Strictes et Ciblées, nous nous y référons en tant que champs MCS.  Malheureusement, ce champ peut contenir le signe ":". La syntaxe de ce champ peut 

http://fedoraproject.org/wiki/Fr_FR/SELinux/ContexteSecurite

Upload file Special pages Printable version Permanent link

ressembler à cela : s0-s15:c1,c2. Mais je parlerais plus tard de la syntaxe. La plupart des  fichiers sont par défaut estampillés s0, parfois, ont fait allusion à SystemLow. Heureusement,  SELinux fournit une bibliothèque de traduction qui remplace les codes du champ par une forme  plus lisible. Alors, quelque chose comme S0:c1,c2 peut être affiché à l'utilisateur comme  PatientRecord,CompanyConfidential. Sur une machine ou la politique est Stricte ou Ciblée, s0  est traduit "", alors la plupart des fichiers n'afficheront pas tous le quatrième champ. 

3ème partie: Types La troisième composante du contexte de sécurité est le champ Type, par  exemple, /usr/sbin/httpd est labélisé avec le type “httpd_exec_t. Mon opinion est que ceci est le  champ le plus important dans le contexte de sécurité SELinux. C’est le cœur du Type  Enforcement de SELinux. La plupart des politiques SELinux tournent autour de quel Type de  Sujet ont quels accès à quels Types d’Objet. Par convention, cette composante se termine  toujours par “_t” 

2nde partie: Rôles La seconde partie du Contexte de Sécurité est le champ Rôle. Ce champ n’est pertinent  uniquement sur les Processus ou les Domaines. Le rôle sur un fichier est toujours object_r, est  n’a vraiment aucune signification autre que de remplir le champ. Sur un Processus, vous verrez  généralement un rôle comme system_r ou sysadm_r. Les rôles sont utilisés pour grouper les  Types de Sécurité. Vous pouvez donc spécifier dans une politique quels rôles sont capables  d’exécuter quels Types. Ceci est la base des RBAC (Roles Based Access Control/ Contrôle  d’Accès Basé sur les Roles) dans SELinux. RBAC ne sont pas réellement utilisés dans les  politiques Ciblés, mais deviennent plus important dans les politiques Strictes et MLS. Les  politiques MLS contiennent aussi sysadm_r, staff_r, and secadm_r. Par convention, les rôles se  terminent toujours par "_r" 

1ère partie: Utilisateurs La première composante du Contexte de Sécurité est le champ "Utilisateur SELinux". Ce composant peut être considéré comme une manière de regrouper les rôles. Les Utilisateurs  SELinux peuvent avoir des multiples rôles, et ensuite, dans ces rôles, ils peuvent avoir de  multiples types. Les trois utilisateurs que vous verrez généralement sur le système sont  "user_u", "system_u" et root. L’utilisateur user_u est l’utilisateur SELinux par défaut pour un  utilisateur connecté sur le système. "system_u" est l’utilisateur par défaut pour les processus  exécutés durant la phase de démarrage. Ils n’ont jamais été démarrés par un utilisateur. "root"  est l’utilisateur SELinux que vous obtenez quand vous vous connectez sur la console en tant  que "root". Dans les politiques Ciblées la composante utilisateur n’est pas vraiment importante.  Cela l’est plus sur les machines à politiques MLS ou strictes. Sur un fichier le champ utilisateur indique l’utilisateur SELinux qui à créé le fichier. Sur les fichiers original du système, les fichiers  sont labélisés system_u. Si vous les re-labélisez ils obtiendront de nouveau le label system_u.  Par convention, tous les utilisateurs SELinux se terminent par "_u" sauf pour root. De base, si  vous souhaitez faire correspondre un utilisateur Linux à un utilisateur SELinux, vous devrez  créer un utilisateur SELinux avec le même nom que l’utilisateur Linux. C’est pour cela que  l’utilisateur root ne se termine pas par "_u". Dans les nouvelles versions de SELinux, nous  avons ajouté un fichier de mappage "seusers" qui vous permet de faire la correspondance entre  les utilisateurs Linux et SELinux sans avoir à créer bon nombre d’utilisateur SELinux.  Retrieved from "https://fedoraproject.org/wiki/Fr_FR/SELinux/ContexteSecurite"

This page was last modified 16:36, 24 May 2008.  Sponsors Legal Trademark Guidelines Copyright © 2008 Red Hat, Inc. and others. All Rights Reserved. Please send any comments or corrections to the websites team.  The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content. 

http://fedoraproject.org/wiki/Fr_FR/SELinux/ContexteSecurite

http://fedoraproject.org/wiki/Fr_FR/SELinux/ContexteSecurite

Personal tools 

Log in

Views 

Article



Discussion



View source



History

Fr FR/SELinux/PolitiqueEnforce

WIKI

Main Page News

From FedoraProject < Fr FR | SELinux

Events Features Recent changes Random page Help



1 Comment SELinux applique les politiques 

1.1 Premièrement, parlons du processus de démarrage 1.2 À propos de unconfined_t et de la procédure d’ouverture de session



1.3 NOTE :



NAVIGATION

Home Get Fedora Join Fedora SUB-PROJECTS

Ambassadors Artwork Bug Zappers Documentation Infrastructure Internationalization Localization Marketing Package Maintainers Websites Weekly News All projects SEARCH

Go  

Contents

Search

TOOLBOX

What links here Related changes Upload file

Comment SELinux applique les  politiques  Premièrement, parlons du processus de démarrage Quand le noyau SELinux démarre il est codé en dur en se lançant en tant que kernel_t. Puisqu'à  ce moment c’est le seul contexte, toutes les applications qui sont exécutées resteront étiquetées  kernel_t. Quand le noyau exécute /sbin/init il est à l’origine exécuté en tant que kernel_t,  ensuite il lit le fichier de politiques et le charge dans le noyau. À ce moment init se réexécute lui  même. Lorsque /sbin/init est installé, il est étiqueté init_exec_t, ensuite une règle dans le  noyau précise que lorsque kernel_t exécute une application étiquetée init_exec_t, elle doit être modifiée en init_t. Dès lors, le processus init s'exécute en que init_t.  Le processus init exécute alors /etc/rc.d/rc.sysinit, qui a été étiqueté initrc_exec_t. Le  noyau possède une règle qui indique que lorsque init_t exécute initrc_exec_t, il doit le  modifier vers initrc_t. Cela continue jusqu'à ce que l’exécutable httpd soit démarré en tant que  httpd_t.  Le noyau va maintenant examiner tout accès (en lecture) du domaine de processus (httpd_t) sur la  classe (fichier) d’objet du système, par exemple : /var/www/index.html (httpd_sys_content_t). Si une règle dans la politique l'autorise, l’accès sera permis. S'il est  refusé, un message AVC (Access Vector Cache) sera inscrit dans le fichier journal. Par ailleurs, ne  me critiquez pas pour AVC, je ne suis pas celui qui en a choisi le nom. 

À propos de unconfined_t et de la procédure d’ouverture  de session  Certaines applications, telles que login, sont autorisées par la politique à définir le contexte du  prochain programme exécuté. Actuellement, la plupart des programmes d’ouverture de session utilisent pam_selinux pour avoir ce comportement.  Quand je me connecte alors au système, pam utilise libselinux pour trouver quel est le contexte 

http://fedoraproject.org/wiki/Fr_FR/SELinux/PolitiqueEnforce

Special pages Printable version Permanent link

initial à paramétrer pour l'utilisateur. Sur un sytème à polique ciblée, cela sera unconfined_t. Vous  pouvez modifier ce comportement en modifiant les fichiers  dans /etc/selinux/POLICYTYPE/contexts/default_contexts et /etc/selinux/POLICYTYPE/contexts/users/ afin que sur un système à politique stricte ou  MLS, vous puissiez paramétrer l'ouverture de session d'un terminal local par défaut sur un certain  contexte, et sur une connexion distante utiliser un contexte différent ; mais cela est une fonctionnalité  avancée. Ainsi, dès que l'utilisateur est connecté, son shell sera lancé avec unconfined_t ou bien user_t,  et chaque accès que l'utilisateur fera passera par le noyau afin d'être sûr que l'accès est autorisé.  Evidemment, tout ceci est mis en mémoire tampon afin d'améliorer les performances du système. 

NOTE :  Une chose étrange que vous aurez pu remarquer est que suivant la méthode de démarrage d'une  application, elle pourra s'exécuter au final dans un contexte différent. Par exemple, si vous exécutez httpd via le script de démarrage de service, il sera lancé en tant que httpd_t, mais si vous  l'exécutez directement, il sera lancé en tant que unconfined_t. Pourquoi ? Il y a une règle dans le noyau précisant que unconfined_t exécutant initrc_exec_t sera transposé vers initrc_t, et  que initrc_t lancant httpd_exec_t sera transposé vers httpd_t. Il existe une autre règle qui  précise que unconfined_t est autorisé à lancer httpd_exec_t sans transposition.  Cela a été une décision consciente prise par les auteurs de la politique afin d'essayer de réduire la  confusion. Les domaines les plus confinés ne sont pas autorisés à discuter avec le terminal. Ils ne  sont également pas autorisés à lire/écrire dans les répertoires des utilisateurs. La raison pour cela est  que nous avons essayer de protéger l'espace utilisateur de l'espace système, et si un domaine cible a  été piraté et qu'il lui est possible de lire/écrire sur une console ou un terminal, il pourrait afficher un  écran d'ouverture de session et ainsi nous permettre de fournir un nom d'utilisateur et un mot de  passe. De même, si un domaine ciblé était capable de lire/écrire dans nos répertoires utilisateur, il  pourrait lire nos numéros de carte de crédit, modifier nos scripts d'authenfication, ou plus  généralement faire des ravages...  Le problème avec cela est que de temps en temps, les administrateurs exécutent le domaine ciblé  avec l'option --help ou veulent tester un script CGI et ne peuvent voir aucun(e) résultat/sortie. Ou  voudraient essayer de rediriger la sortie vers leur répertoire utilisateur.  ./MonScriptCGI

>> ~toto.out

Si ces domaines venaient à se croiser, ces accès seraient interdits et l'utilisateur pourrait mettre un  certain temps à comprendre ce qu'il se passe. Donc, si vous désirez exécuter un domaine ciblé dans un contexte verrouillé, vous aurez besoin  d'utiliser les scripts d'init.  Retrieved from "https://fedoraproject.org/wiki/Fr_FR/SELinux/PolitiqueEnforce"

This page was last modified 16:34, 24 May 2008.  Sponsors Legal Trademark Guidelines Copyright © 2008 Red Hat, Inc. and others. All Rights Reserved. Please send any comments or corrections to the websites team.  The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content. 

http://fedoraproject.org/wiki/Fr_FR/SELinux/PolitiqueEnforce

http://fedoraproject.org/wiki/Fr_FR/SELinux/PolitiqueEnforce

Personal tools 

Log in

Views 

Article



Discussion



View source

View source

WIKI

Main Page News

From FedoraProject for Fr FR/SELinux/ApplicationSELinux

Events Features

You are not allowed to execute the action you have requested. 

Recent changes

Return to Main Page.

Random page Retrieved from "https://fedoraproject.org/wiki/Fr_FR/SELinux/ApplicationSELinux"

Help NAVIGATION

Home Get Fedora Join Fedora SUB-PROJECTS

Ambassadors Artwork Bug Zappers Documentation Infrastructure Internationalization Localization Marketing Package Maintainers Websites Weekly News All projects SEARCH

Go  

Search

TOOLBOX

What links here Upload file Special pages Sponsors

Legal

Trademark Guidelines

Copyright © 2008 Red Hat, Inc. and others. All Rights Reserved. Please send any comments or corrections to the websites team.  The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content. 

http://fedoraproject.org/w/index.php?title=Fr_FR/SELinux/ApplicationSELinux&action=edit

Personal tools 

Log in

Views 

Article



Discussion



View source

View source

WIKI

From FedoraProject

Main Page News

for Fr FR/SELinux/Connexion

Events Features

You are not allowed to execute the action you have requested. 

Recent changes

Return to Main Page.

Random page Retrieved from "https://fedoraproject.org/wiki/Fr_FR/SELinux/Connexion"

Help NAVIGATION

Home Get Fedora Join Fedora SUB-PROJECTS

Ambassadors Artwork Bug Zappers Documentation Infrastructure Internationalization Localization Marketing Package Maintainers Websites Weekly News All projects SEARCH

Go  

Search

TOOLBOX

What links here Upload file Special pages Sponsors

Legal

Trademark Guidelines

Copyright © 2008 Red Hat, Inc. and others. All Rights Reserved. Please send any comments or corrections to the websites team.  The Fedora Project is maintained and driven by the community and sponsored by Red Hat. This is a community maintained site. Red Hat is not responsible for content. 

http://fedoraproject.org/w/index.php?title=Fr_FR/SELinux/Connexion&action=edit

Personal tools 

Log in

Views 

Article



Discussion



View source



History

Fr FR/SELinux/Config

WIKI

Main Page News

From FedoraProject < Fr FR | SELinux

Events Features Recent changes Random page Help NAVIGATION

/etc/selinux/config Le fichier de configuration original de SELinux se trouve dans /etc/sysconfig/selinux et il existe  également un lien vers /etc/selinux/config. Ou toute la magie de SELinux démarre. Libselinux lit ce  fichier pour consulter de quelle manière SELinux est configuré.  Ce fichier ressemble généralement à cela: 

Home Get Fedora

SELINUX=enforcing

Join Fedora

SELINUXTYPE=targeted

SUB-PROJECTS

Dans FC5 il y à deux variables additionnelles dont je parlerais plus tard. 

Ambassadors Artwork

# SETLOCALDEFS= Check local definition changes

Bug Zappers

SETLOCALDEFS=0

Documentation Infrastructure Internationalization Localization

ce fichier est lu par SELinux et sert à determiner dans quel mode SELinux s'exécute et quelle  politique utiliser. Lors du démarrage de la machine, init utilise libselinux pour lire ce fichier et  détermine quelle politique doit être charger et dans quel mode placer la machine. 

Marketing Package Maintainers Websites Weekly News All projects SEARCH

Go  

Search

Variables 

SELINUX - variable qui peut prendre trois valeurs distinctes. 

 

Enforcing  Cela informe le système de s'exécuter avec SELinux scrutant tous les accès au système et de 



stoper tout accès "refusé".  Ce devrait être le mode par défaut. 



TOOLBOX

What links here



Related changes



Upload file

Le noyau bloque tout les accès à moins qu'ils n'aient été explicitement autorisés. Tout accès refusé et renseigné dans le journal système en tant que AVC (accès Vector Cache), à moins  qu'un auteur de politique ai explicitement informé le noyau de ne pas auditer le message.  Permissive 



Le noyau rapportera toute violation d'accès en tant que message AVC mais permettra l'accès.  Le noyau continuera de correctement labéliser les fichiers. 



Il y a un nombre majeur de différences avec lesquelle le noyau inscrit ces messages AVC. 

1. Le noyau inscrira seulement la première violation d'accès en mode permissif pour un Domaine  Confiné sur un objet particulier, le mode renforcé inscrira chaque accès refusé. 2. Vous pouvez avoir  de nombreux messages AVC additionnel qui n'auraient jamais dû s'afficher en mode renforcé. Par  exemple, si un Domaine Confiné n'est pas autorisé à lire un répertoire ou n'importe quel fichier se

http://fedoraproject.org/wiki/Fr_FR/SELinux/Config