NB Overview FR

From SELinux Wiki
Jump to: navigation, search

SELinux Overview

Introduction

Ceci est la traduction française de la page originale NB Overview écrite en anglais.

SELinux est le mécanisme primaire de Contrôle d'Accès Obligatoire (Mandatory Access Control =MAC) mechanism construit au sein d'un bon nombre de distributions GNU / Linux. SELinux a débuté en tant que développement du Noyau de sécurité à Flux Avancés (Flux Advanced Security Kernel = FLASK) par l'équipe FLUX de l'université d'Utah et le département de la défense Américain. Le développement a été amélioré par la NSA et distribué comme logiciel libre. L'histoire de SELinux peut être trouvée sur les sites web Flux et NSA.

Les sections suivantes décrivent chacune un composant SELinux dans une forme et un ordre que nous espérons logiques.

Note: Une fois installé, SELinux définit trois répertoires bien précis. Deux d'entre eux changeront avec les anciennes et nouvelles localisations comme suit:


Description
Ancienne Localisation
NouvelleLocalisation
Le système de fichiers SELinux qui s'interface avec le serveur de sécurité basé sur le noyau.

Les nouvelles localisations sont disponibles depuis Fedora 17.

/selinux /sys/fs/selinux
Le répertoire de configuration SELinux qui contient les fichiers de configuration du sous-système et les politiques. /etc/selinux Aucun changement
Le magasin de politiques SELinux qui renferme les modules de politique et les détails de configuration (cfr. https://github.com/SELinuxProject/selinux/wiki/Policy-Store-Migration et Policy Store Migration). /etc/selinux/<SELINUXTYPE>/module /var/lib/selinux/<SELINUXTYPE>/module


Is SELinux useful

There are many views on the usefulness of SELinux on Linux based systems, this section gives a brief view of what SELinux is good at and what it is not (because its not designed to do it).

SELinux is not just for military or high security systems where Multi-Level Security (MLS) is required (for functionality such as 'no read up' and 'no write down'), as using the 'type enforcement' (TE) functionality applications can be confined (or contained) within domains and limited to the mimimum privileges required to do their job, so in a 'nutshell':

  1. If SELinux is enabled, the policy defines what access to resources and operations on them (e.g. read, write) are allowed (i.e. SELinux stops all access unless allowed by policy). This is why SELinux is called a 'mandatory access control' (MAC) system.
  2. The policy design, implementation and testing against a defined security policy or requirements is important, otherwise there could be 'a false sense of security'.
  3. SELinux can confine an application within its own 'domain' and allow it to have the minimum priviledges required to do its job. Should the application require access to networks or other applications (or their data), then (as part of the security policy design), this access would need to be granted (so at least it is known what interactions are allowed and what are not - a good security goal).
  4. Should an application 'do something' it is not allowed by policy (intentional or otherwise), then SELinux would stop these actions.
  5. Should an application 'do something' it is allowed by policy, then SELinux may contain any damage that maybe done intentional or otherwise. For example if an application is allowed to delete all of its data files or database entries and the bug, virus or malicious user gains these priviledges then it would be able to do the same, however the good news is that if the policy 'confined' the application and data, all your other data should still be there.
  6. User login sessions can be confined to their own domains. This allows clients they run to be given only the priviledges they need (e.g. admin users, sales staff users, HR staff users etc.). This again will confine/limit any damage or leakage of data.
  7. Some applications (X-Windows for example) are difficult to confine as they are generally designed to have total access to all resources. SELinux can generally overcome these issues by providing sandboxing services.
  8. SELinux will not stop memory leaks or buffer over-runs (because its not designed to do this), however it may contain the damage that may be done.
  9. SELinux will not stop all viruses/malware getting into the system (as there are many ways they could be introduced (including by legitimate users), however it should limit the damage or leaks they cause.
  10. SELinux will not stop kernel vulnerabilities, however it may limit their effects.
  11. It is easy to add new rules to an SELinux policy using tools such as audit2allow(1) if a user has the relevant permissions, however be aware that this may start opening holes, so check what rules are really required.
  12. Finally, SELinux cannot stop anything allowed by the security policy, so good design is important.

The following maybe useful in providing a practical view of SELinux:

However with careful design and known security goals the SELinux Apache / SELinux Plus services could be used to build a more secure web service (also see http://code.google.com/p/sepgsql/wiki/Apache_SELinux_plus).

  • SELinux services have been added to Andriod, producing SE for Android. The presentation "The Case for Security Enhanced (SE)Android" gives use-cases and types of Android exploits that SELinux could have overcome. The presentation and others are available at:

http://seandroid.bitbucket.org/PapersandPresentations.html#3


Previous
Home
Next