Começando com SELinux
Esta página foi convertida do Fedora Project Wiki e limpa para publicação aqui no Fedora Docs Portal, mas ainda não foi revisada quanto à precisão técnica. Isso significa que qualquer informação nesta página pode estar desatualizada ou imprecisa. Avaliações de precisão técnica são muito apreciadas. Se você quiser ajudar, consulte o link: README arquivo no repositório de origem para obter instruções.
Introdução ao SELinux
Security Enhanced Linux (SELinux) provê uma camada adicional de segurança do sistema. SELinux fundamentalmente responde a pergunta: Tal <serviço> pode fazer tal <ação> ao <objeto>?, por exemplo: Um servidor web pode acessar arquivos nas pastas da home do usuário?
The standard access policy based on the user, group, and other permissions, known as Discretionary Access Control (DAC), does not enable system administrators to create comprehensive and fine-grained security policies, such as restricting specific applications to only viewing log files, while allowing other applications to append new data to the log files.
SELinux implements Mandatory Access Control (MAC). Every process and system resource has a special security label called a SELinux context. A SELinux context, sometimes referred to as a SELinux label, is an identifier which abstracts away the system-level details and focuses on the security properties of the entity. Not only does this provide a consistent way of referencing objects in the SELinux policy, but it also removes any ambiguity that can be found in other identification methods; for example, a file can have multiple valid path names on a system that makes use of bind mounts.
The SELinux policy uses these contexts in a series of rules which define how processes can interact with each other and the various system resources. By default, the policy does not allow any interaction unless a rule explicitly grants access.
It is important to remember that SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first, which means that no SELinux denial is logged if the traditional DAC rules prevent the access.
SELinux contexts have several fields: user, role, type, and security level. The SELinux type information is perhaps the most important when it comes to the SELinux policy, as the most common policy rule which defines the allowed interactions between processes and system resources uses SELinux types and not the full SELinux context. SELinux types usually end with
_t. For example, the type name for the web server is
httpd_t. The type context for files and directories normally found in
httpd_sys_content_t. The type contexts for files and directories normally found in
tmp_t. The type context for web server ports is
For example, there is a policy rule that permits Apache (the web server process running as
httpd_t) to access files and directories with a context normally found in
/var/www/html/ and other web server directories (
httpd_sys_content_t). There is no allow rule in the policy for files normally found in
/var/tmp/, so access is not permitted. With SELinux, even if Apache is compromised, and a malicious script gains access, it is still not able to access the
To better understand SELinux basic concepts, see the following documentation:
Benefícios de usar SELinux
SELinux oferece os seguintes benefícios:
All processes and files are labeled. SELinux policy rules define how processes interact with files, as well as how processes interact with each other. Access is only allowed if an SELinux policy rule exists that specifically allows it.
Fine-grained access control. Stepping beyond traditional UNIX permissions that are controlled at user discretion and based on Linux user and group IDs, SELinux access decisions are based on all available information, such as an SELinux user, role, type, and, optionally, a security level.
SELinux policy is administratively-defined and enforced system-wide.
Improved mitigation for privilege escalation attacks. Processes run in domains, and are therefore separated from each other. SELinux policy rules define how processes access files and other processes. If a process is compromised, the attacker only has access to the normal functions of that process, and to files the process has been configured to have access to. For example, if the Apache HTTP Server is compromised, an attacker cannot use that process to read files in user home directories, unless a specific SELinux policy rule was added or configured to allow such access.
SELinux can be used to enforce data confidentiality and integrity, as well as protecting processes from untrusted inputs.
However, SELinux is not:
replacement for passwords, firewalls, and other security systems,
all-in-one security solution.
SELinux is designed to enhance existing security solutions, not replace them. Even when running SELinux, it is important to continue to follow good security practices, such as keeping software up-to-date, using hard-to-guess passwords, or firewalls. :experimental:
Exemplos do SELinux
The following examples demonstrate how SELinux increases security:
The default action is deny. If an SELinux policy rule does not exist to allow access, such as for a process opening a file, access is denied.
SELinux can confine Linux users. A number of confined SELinux users exist in SELinux policy. Linux users can be mapped to confined SELinux users to take advantage of the security rules and mechanisms applied to them. For example, mapping a Linux user to the SELinux
user_uuser, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as
su, as well as preventing them from executing files and applications in their home directory. If configured, this prevents users from executing malicious files from their home directories.
Increased process and data separation. Processes run in their own domains, preventing processes from accessing files used by other processes, as well as preventing processes from accessing other processes. For example, when running SELinux, unless otherwise configured, an attacker cannot compromise a Samba server, and then use that Samba server as an attack vector to read and write to files used by other processes, such as MariaDB databases.
SELinux helps mitigate the damage made by configuration mistakes. Domain Name System (DNS) servers often replicate information between each other in what is known as a zone transfer. Attackers can use zone transfers to update DNS servers with false information. When running the Berkeley Internet Name Domain (BIND) as a DNS server in Fedora, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files  from being updated using zone transfers, by the BIND
nameddaemon itself, and by other processes.
See the NetworkWorld.com article, A seatbelt for server software: SELinux blocks real-world exploits, for background information about SELinux, and information about various exploits that SELinux has prevented. :experimental:
Arquitetura do SELinux
SELinux é um módulo de segurança do Linux (LSM) integrado ao kernel do Linux. O subsistema SELinux no kernel é conduzido por uma política de segurança que é controlada pelo administrador e carregada na inicialização. Todas as operações de acesso relevantes para a segurança no nível do kernel no sistema são interceptadas pelo SELinux e examinadas no contexto da política de segurança carregada. Se a política carregada permitir a operação, ela continuará. Caso contrário, a operação é bloqueada e o processo recebe um erro.
As decisões do SELinux, como permitir ou não o acesso, são armazenadas em cache. Esse cache é conhecido como Access Vector Cache (AVC). Ao usar essas decisões em cache, as regras de política do SELinux precisam ser menos verificadas, o que aumenta o desempenho. Lembre-se de que as regras de política SELinux não têm efeito se as regras DAC negarem o acesso primeiro. :experimental:
Estados e modos do SELinux
O SELinux pode rodar em um de três modos: desabilitado, permissivo ou reforçado.
Disabled mode is strongly discouraged; not only does the system avoid enforcing the SELinux policy, it also avoids labeling any persistent objects such as files, making it difficult to enable SELinux in the future.
In permissive mode, the system acts as if SELinux is enforcing the loaded security policy, including labeling objects and emitting access denial entries in the logs, but it does not actually deny any operations. While not recommended for production systems, permissive mode can be helpful for SELinux policy development.
Enforcing mode is the default, and recommended, mode of operation; in enforcing mode SELinux operates normally, enforcing the loaded security policy on the entire system.
setenforce utility to change between enforcing and permissive mode. Changes made with
setenforce do not persist across reboots. To change to enforcing mode, enter the
setenforce 1 command as the Linux root user. To change to permissive mode, enter the
setenforce 0 command. Use the
getenforce utility to view the current SELinux mode:
~]# getenforce Enforcing
~]# setenforce 0 ~]# getenforce Permissive
~]# setenforce 1 ~]# getenforce Enforcing
In Fedora, you can set individual domains to permissive mode while the system runs in enforcing mode. For example, to make the
httpd_t domain permissive:
~]# semanage permissive -a httpd_t
Want to help? Learn how to contribute to Fedora Docs ›