SELinuxの始め方

The Fedora Docs Team, Peter Boy (pboy) Version F35-F38 Last review: 2023-09-08

SELinuxの導入

Security Enhanced Linux（SELinux）を使用することで、システムのセキュリティを一段階強化することができます。SELinuxとは本質的には、「（主語）が（目的語）に（アクション）をしてもよいか？」というのを判断する仕組みです。例えば、「ウェブサーバーがユーザーのホームディレクトリーにアクセスしてもよいか？」といったものです。

一般的に使われている、ユーザーやグループなどに基づくアクセスポリシーは、Discretionary Access Control（DAC）と呼ばれますが、網羅的かつ詳細なセキュリティポリシーを管理者が設定できません。例えば、特定のアプリケーションに対してログファイルの読み込みだけを許可しつつ、他のアプリケーションにはログファイルにデータの追加を許可する、といったポリシーです。

SELinuxはMandatory Access Control（MAC）と呼ばれるものを実装しています。すべてのプロセスおよびシステムリソースに、 SELinuxコンテキスト と呼ばれる特別なセキュリティラベルが付与されています。SELinuxコンテキストは、 SELinuxラベル と呼ばれることもありますが、システムレベルの詳細な情報をより抽象化した識別子であり、当該のエンティティのセキュリティ属性に重きを置きます。これにより、SELinuxのポリシーにおいてオブジェクトを指定する方法が一貫性のあるものになるだけでなく、他の識別方法に見られる曖昧性を排除することにもなります。例えば、バインドマウントを使用しているシステムでは、同一のファイルが複数の有効なパスを持つことがあります。

SELinuxポリシーでは、このコンテキストを使って、プロセスが他のプロセスや様々なシステムリソースにどうアクセスできるかをルールとして定義します。デフォルトでは、アクセスを明示的に許可するルールがなければそのアクセスは許可されません。

重要なのが、SELinuxポリシーのルールはDACルールがチェックされたあとにチェックされるという点です。DACルールが最初にアクセスを拒否すると、SELinuxポリシーのルールは使われず、ログにもSELinuxによるアクセス拒否は記録されません。

SELinuxコンテキストはユーザー、ロール、タイプ、セキュリティレベル、というフィールドから構成されます。SELinuxポリシーにおいて一番重要なのはおそらくタイプです。プロセスとシステムリソースのやり取りを許可するルールでは、コンテキストすべてではなくタイプだけを使用することが最も多いからです。SELinuxタイプは通常、末尾が _t となっています。例えば、ウェブサーバー用のタイプは httpd_t です。通常 /var/www/html/ に存在するファイルやディレクトリには httpd_sys_content_t タイプを持っています。通常 /tmp や /var/tmp/ にあるファイルやディレクトリは tmp_t です。ウェブサーバーが使用するポートのタイプは http_port_t です。

例えば、Apacheサーバー（ウェブサーバープロセスが httpd_t として実行される）が、 /var/www/html/ といったウェブサーバー用ファイル・ディレクトリ（ httpd_sys_content_t ）にアクセスできるようにするポリシールールが存在します。しかし、 /tmp や /var/tmp/ にあるファイルへのアクセスを許可するルールはないため、アクセスは拒否されます。SELinuxのおかげで、もしApacheが乗っ取られて悪性なスクリプトが侵入しても、 /tmp ディレクトリにアクセスすることができません。

SELinux_Apache_MariaDB_example
Figure 1. SELinux により、httpd_tとして実行されているApacheプロセスは /var/www/html/ ディレクトリにアクセスできる一方で、/data/mysql/ ディレクトリにはアクセスできません。httpd_t と mysqld_db_t タイプについての許可ルールがないからです。一方で、mysqld_tとして実行されているMariaDBプロセスは /data/mysql/ ディレクトリにアクセスできますが、httpd_sys_content_tタイプが付与されている /var/www/html/ ディレクトリへのアクセスは正しく拒否されます。

追加資料

SELinuxの基本的な概念についてより深く理解するには、以下のドキュメントを参照してください。

SELinuxを使用するメリット

SELinuxには以下のメリットがあります。

  • すべてのプロセスとファイルがラベル付けされます。プロセスがファイルや他のプロセスをどう操作できるかは、SELinuxポリシーのルールによって定義されます。明示的に許可するポリシールールが存在するときにのみ、アクセスできます。

  • 粒度の細かいアクセス制御。従来のUNIXの権限システムはユーザー任せであり、Linuxユーザー・グループのIDによって制御しますが、SELinuxはそれをさらに改善し、SELinuxユーザー、ロール、タイプ、セキュリティレベル（必須ではない）のような情報をすべて用いてアクセス制御ができます。

  • 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:

  • antivirus software,

  • 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.

SELinux examples

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_u user, results in a Linux user that is not able to run (unless configured otherwise) set user ID (setuid) applications, such as sudo and 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 [1] from being updated using zone transfers, by the BIND named daemon itself, and by other processes.

  • See the NetworkWorld.com article, A seatbelt for server software: SELinux blocks real-world exploits[2], for background information about SELinux, and information about various exploits that SELinux has prevented.

SELinux architecture

SELinux is a Linux Security Module (LSM) that is built into the Linux kernel. The SELinux subsystem in the kernel is driven by a security policy which is controlled by the administrator and loaded at boot. All security-relevant, kernel-level access operations on the system are intercepted by SELinux and examined in the context of the loaded security policy. If the loaded policy allows the operation, it continues. Otherwise, the operation is blocked and the process receives an error.

SELinux decisions, such as allowing or disallowing access, are cached. This cache is known as the Access Vector Cache (AVC). When using these cached decisions, SELinux policy rules need to be checked less, which increases performance. Remember that SELinux policy rules have no effect if DAC rules deny access first.

SELinux states and modes

SELinux can run in one of three modes: disabled, permissive, or enforcing.

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.

Use the 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
1. Text files that include information, such as host name to IP address mappings, that are used by DNS servers.
2. Marti, Don. "A seatbelt for server software: SELinux blocks real-world exploits". Published 24 February 2008. Accessed 27 August 2009: https://www.networkworld.com/article/2283723/lan-wan/a-seatbelt-for-server-software--selinux-blocks-real-world-exploits.html.

Want to help? Learn how to contribute to Fedora Docs ›