思考の道具箱

2. Introduction　入門

これから、ディレクトリやデバイス、そしてファイルなどを、操作の対象＝オブジェクトと呼びます。
そして、ユーザが実行しているコマンドや、Mozilla Firefoxなどのアプリケーションを操作の主体＝subjectと呼びます。

大抵のＯＳでは、任意アクセス制御（DAC：Discretionary Access Control）という仕組が採用されています。これは、操作の主体(subject)がどのようにオブジェクトを操作するか、および、操作の主体同士がどのようにアクセスしあうのかを制御する仕組です。任意アクセス制御(DAC)を採用しているＯＳでは、ファイル（object）を所有しているユーザ(subject)が、ファイルのパーミッションを決めます。
例えば、Linuxでは、ユーザは自分のホームディレクトリを誰でも読めるようにして、他のユーザやプロセスが本来は秘密にしておくべき情報にアクセスできるように設定できます。
Files, such as directories and devices, are called objects. Processes, such as a user running a command or the Mozilla® Firefox® application, are called subjects. Most operating systems use a Discretionary Access Control (DAC) system that controls how subjects interact with objects, and how subjects interact with each other. On operating systems using DAC, users control the permissions of files (objects) that they own. For example, on Linux® operating systems, users can make their home directories world-readable, giving users and processes (subjects) access to potentially sensitive information.

任意アクセス制御(DAC)の仕組は、堅固なセキュリティを必要とするシステムにはもともと向いていません。任意アクセス制御は、ユーザの認証と、所有関係だけに基づくもので、それ以外のセキュリティの要件や情報、例えばユーザの役割や、プログラムの機能と信頼性、そして、データの機密性や一貫性などは考慮されません。
それぞれのユーザが所有するファイルについては完全に自由にアクセス権を設定できるので、システム全体としてのセキュリティポリシーの一貫性を保つように強制することはできません。さらに、ユーザが実行したコマンドは、そのユーザが持っている権限をすべて引き継いでおり、そのユーザが所有しているファイルを自由にアクセスできるため、悪意あるプログラムからユーザを守ることはできません。
大抵のサービスや管理者権限で実行されるプログラムは、本来必要としないほど大雑把な権限を与えられて実行されています。したがって、それらのプログラムに欠陥があれば、システム全体にアクセスされてしまうことになります。
DAC mechanisms are fundamentally inadequate for strong system security. DAC access decisions are only based on user identity and ownership, ignoring other security-relevant information such as the role of the user, the function and trustworthiness of the program, and the sensitivity and integrity of the data. Each user has complete discretion over their files, making it impossible to enforce a system-wide security policy. Furthermore, every program run by a user inherits all of the permissions granted to the user and is free to change access to the user's files, so no protection is provided against malicious software. Many system services and privileged programs must run with coarse-grained privileges that far exceed their requirements, so that a flaw in any one of these programs can be exploited to obtain complete system access.[1]

以下の例は、SELinuxを実行していないLinuxのパーミッションの例です。パーミッションの詳細はシステムによって異なるでしょう。
まず、ls -l コマンドでfile1というファイルのパーミッションを見てみます。
The following is an example of permissions used on Linux operating systems that do not run Security-Enhanced Linux (SELinux). The permissions in these examples may differ from your system. Use the ls -l command to view file permissions:

$ ls -l file1

• rwxrw-r-- 1 user1 group1 0 2008-11-21 15:42 file1

最初の３つのパーミッションのビットrwxは、このファイルの所有者であるuser1ユーザのアクセス権です。
次の３つのパーミッションのビットrw-は、group1というグループのアクセス権です。
最後の３つのパーミッションのビットr--は、ユーザuser1でもなく、グループgroup1にも所属していない、他の全ユーザおよびプロセスのfile1に対するアクセス権です。
The first three permission bits, rwx, control the access the Linux user1 user (in this case, the owner) has to file1. The next three permission bits, rw-, control the access the Linux group1 group has to file1. The last three permission bits, r--, control the access everyone else has to file1, which includes all users and processes.

SELinuxは、Linuxのkernelに強制アクセス制御(MAC: Mandatory Access Control)の機能を付け加えます。Fedoraのディストリビューションでは、SELinuxはデフォルトで有効になっています。
汎用の強制アクセス制御の仕組では、管理者が設定したセキュリティポリシーを、全てのプロセスとファイルについてセキュリティ上の要件に基づいてつけられたラベルから判断して、強制することができなければなりません。

Security-Enhanced Linux (SELinux) adds Mandatory Access Control (MAC) to the Linux kernel, and is enabled by default in Fedora. A general purpose MAC architecture needs the ability to enforce an administratively-set security policy over all processes and files in the system, basing decisions on labels containing a variety of security-relevant information. When properly implemented, it enables a system to adequately defend itself and offers critical support for application security by protecting against the tampering with, and bypassing of, secured applications. MAC provides strong separation of applications that permits the safe execution of untrustworthy applications. Its ability to limit the privileges associated with executing processes limits the scope of potential damage that can result from the exploitation of vulnerabilities in applications and system services. MAC enables information to be protected from legitimate users with limited authorization as well as from authorized users who have unwittingly executed malicious applications.[2]

次の例は、SELinuxが有効になっているLinuxで、各ユーザ、プロセス、そしてファイルが利用するセキュリティ情報をあらわすラベルの例です。この情報をSELinuxのコンテクスト(context)と呼びます。ls -Z というコマンドで表示できます。
The following is an example of the labels containing security-relevant information that are used on processes, Linux users, and files, on Linux operating systems that run SELinux. This information is called the SELinux context, and is viewed using the ls -Z command:

$ ls -Z file1

• rwxrw-r-- user1 group1 unconfined_u:object_r:user_home_t:s0 file1

この例では、通常のパーミッションの情報のほかに、file1のユーザとしての情報(unconfined_u)、役割の情報(object_r)、タイプの情報(user_home_t)、そしてセキュリティのレベルの情報が表示されています。
これらの情報を使って、アクセス制御がされます。任意アクセス制御の場合、アクセスが許可されるかどうかは、ユーザIDだけで決まるのが原則でしたが、SELinuxのセキュリティポリシーは、任意アクセス制御のルールで許可された後で、さらにチェックされます。
In this example, SELinux provides a user (unconfined_u), a role (object_r), a type (user_home_t), and a level (s0). This information is used to make access control decisions. With DAC, access is controlled based only on Linux user and group IDs. SELinux policy rules are checked after DAC rules. SELinux policy rules are not used if DAC rules deny access first.

LinuxとSELinuxでのユーザの定義について
Linux and SELinux Users

SELinuxが有効になっているLinuxでは、それぞれのLinuxのユーザは、SELinuxの環境でもユーザとして扱われます。
SELinuxのユーザ定義は、SELiuxのセキュリティポリシーの一部です。大抵は、Linuxのユーザ定義は、対応するSELinuxユーザがありますが、このドキュメントでは、混乱を防ぐために、なるべくLinuxのユーザとSELinuxのユーザの概念は区別しておくことにします。
On Linux operating systems that run SELinux, there are Linux users as well as SELinux users. SELinux users are part of SELinux policy. Linux users are mapped to SELinux users. To avoid confusion, this guide uses "Linux user" and "SELinux user" to differentiate between the two.

2.1. Benefits of running SELinux　どんないいことがあるか

• 全てのプロセスとファイルのラベルにはタイプ付けがされます（抜けは無い）。プロセスのタイプはプロセスが実行されるドメイン（領域）を指定します。ファイルのタイプはまさしくタイプわけです。プロセスは実行されるべきドメインによって分類、隔離されます。SELinuxのセキュリティポリシーは、ドメインというまとまりごとにプロセスがどんなファイルにアクセスできるか、それぞれのプロセス同士がどのようにアクセスし合うかを定義していきます。あるドメインのプロセスが、特定のタイプのファイルやプロセスにアクセスを許可するようなセキュリティポリシーが無い限り、デフォルトではアクセスは拒絶されます。

All processes and files are labeled with a type. A type defines a domain for processes, and a type for files. Processes are separated from each other by running in their own domains, and 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.

• 決め細やかなアクセス制御ができます。これまでのUNIXのユーザIDに基づく任意アクセス制御のパーミッションの仕組からさらに進んで、SELinuxではユーザID、役割、タイプそして、機密レベルなどの全ての情報を利用して強制アクセス制御が可能です。

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

• SELinuxのセキュリティポリシーは、システム管理者が決定して、システム全体で一貫して運用できます。各ユーザに勝手に変更されたりはしません。

SELinux policy is administratively-defined, enforced system-wide, and is not set at user discretion.

• 権限上昇を狙った攻撃に対して、システムが耐性を強めることができます。一つの例として：それぞれのプロセスはドメインの中で実行され、お互いに隔離されています。そして、SELinuxによってそれぞれのプロセスがアクセスするファイルやプロセスは既定されています。もし、あるプロセスが乗っ取られたとしても、そのプロセスができることは、あらかじめ決められたことだけで、他のことはできません。例えば、ApacheのHTTPサーバが攻撃を受けて乗っ取られたとしても、あらかじめポリシーで設定されているディレクトリを除いては攻撃者はサーバのプロセスを使って、ユーザのホームディレクトリのファイルを覗き見することはできません。

Reduced vulnerability to privilege escalation attacks. One example: since processes run in domains, and are therefore separated from each other, and 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 can not 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はデータの機密性や一貫性を守る助けになります。また、プロセスが外部からの入力によって攻撃されるのを守る働きもあります。

SELinux can be used to enforce data confidentiality and integrity, as well as protecting processes from untrusted inputs.

SELinuxは、次のようなものではありません
SELinux is not:

• アンチウィルスソフトではありません。

antivirus software.

• パスワードや、ファイアウォール、市販のセキュリティ管理ソフトとも違います。

a replacement for passwords, firewalls, or other security systems.

• それだけで全て安心、というようなセキュリティパッケージソフトではありません

an all-in-one security solution.

SELinuxは既存のセキュリティ確保の手段を補強するものです。SELinuxを実行していても、コレまでどおりセキュリティの基本的な事項は守られなくてはなりません。ソフトウェアのアップデートは怠れませんし、パスワードは推測されにくいものを使わねばいけません。ファイアウォールも依然として必要です。
SELinux is designed to enhance existing security solutions, not replace them. Even when running SELinux, continue to follow good security practices, such as keeping software up-to-date, using hard-to-guess passwords, firewalls, and so on.

2.2. 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. Linux users can be mapped to SELinux users to take advantage of confined SELinux users. 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. *

process separation. Processes run in their own domains, preventing processes from accessing files used by other processes, as well as processes accessing other processes. For example, when running SELinux, unless otherwise configured, an attacker can not compromise a Samba server, and then use that Samba server to read and write to files used by other processes, such as databases used by MySQL®. *

help limit the damage done by configuration mistakes. Domain Name System (DNS) servers can replicate information between each other. This 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) DNS server in Fedora 10, even if an administrator forgets to limit which servers can perform a zone transfer, the default SELinux policy prevents zone files [3] from being updated by zone transfers, the BIND named daemon, and other processes. *

refer to the Red Hat® Magazine article, Risk report: Three years of Red Hat Enterprise Linux 4[4], for exploits that were restricted due to the default SELinux targeted policy in Red Hat® Enterprise Linux® 4. *

refer to the LinuxWorld.com article, A seatbelt for server software: SELinux blocks real-world exploits[5], for background information about SELinux, and information about various exploits that SELinux has prevented. *

refer to James Morris's SELinux mitigates remote root vulnerability in OpenPegasus blog post, for information about an exploit in OpenPegasus that was mitigated by SELinux as shipped with Red Hat Enterprise Linux 4 and 5.

The Tresys Technology website has an SELinux Mitigation News section (on the right-hand side), that lists recent exploits that have been mitigated or prevented by SELinux.

2.3. SELinux Architecture　アーキテクチャ

SELinux is a Linux security module that is built into the Linux kernel. SELinux is driven by loadable policy rules. When security-relevant access is taking place, such as when a process attempts to open a file, the operation is intercepted in the kernel by SELinux. If an SELinux policy rule 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). Caching decisions decreases how often SELinux policy rules need to be checked, which increases performance. SELinux policy rules have no affect if DAC rules deny access first.

2.4. SELinux on Other Operating Systems 他のＯＳではどうか

Refer to the following for information about running SELinux on operating systems:

*

Hardened Gentoo: http://www.gentoo.org/proj/en/hardened/selinux/sel... *

Debian: http://wiki.debian.org/SELinux. *

Ubuntu: https://wiki.ubuntu.com/SELinux and https://help.ubuntu.com/community/SELinux. *

Red Hat Enterprise Linux: Red Hat Enterprise Linux Deployment Guide and Red Hat Enterprise Linux 4 SELinux Guide. *

Fedora: http://fedoraproject.org/wiki/SELinux and the Fedora Core 5 SELinux FAQ.