Introduction to the Red Hat SELinux Guide
This section is a very brief overview of SELinux. More detail is given in and .
Security-enhanced Linux (
SELinux) is an implementation of a
mandatory access control mechanism. This mechanism is in the Linux kernel, checking for allowed operations after standard Linux
discretionary access controls are checked.
To understand the benefit of mandatory access control (
MAC) over traditional discretionary access control (
DAC), you need to first understand the limitations of DAC.
Under DAC, ownership of a file object provides potentially crippling or risky control over the object. A user can expose a file or directory to a security or confidentiality breach with a misconfigured chmod command and an unexpected propagation of access rights. A process started by that user, such as a CGI script, can do anything it wants to the files owned by the user. A compromised Apache HTTP server can perform any operation on files in the Web group. Malicious or broken software can have root-level access to the entire system, either by running as a root process or using setuid or setgid.
Under DAC, there are really only two major categories of users, administrators and non-administrators. In order for services and programs to run with any level of elevated privilege, the choices are few and course grained, and typically resolve to just giving full administrator access. Solutions such as
ACLs (
access control lists) can provide some additional security for allowing non-administrators expanded privileges, but for the most part a root account has complete discretion over the file system.
A MAC or non-discretionary access control framework allows you to define permissions for how all processes (called subjects) interact with other parts of the system such as files, devices, sockets, ports, and other processes (called objects in SELinux). This is done through an administratively-defined security policy over all processes and objects. These processes and objects are controlled through the kernel, and security decisions are made on all available information rather than just user identity. With this model, a process can be granted just the permissions it needs to be functional. This follows the principle of least privilege. Under MAC, for example, users who have exposed their data using chmod are protected by the fact that their data is a kind only associated with user home directories, and confined processes cannot touch those files without permission and purpose written into the policy.
SELinux is implemented in the Linux kernel using the
LSM (
Linux Security Modules) framework. This is only the latest implementation of an ongoing project, as detailed in . To support fine-grained access control, SELinux implements two technologies:
Type Enforcement™ (
TE) and a kind of
role-based access control (
RBAC), which are discussed in
Chapter 1 SELinux Architectural Overview.
Type Enforcement involves defining a
type for every subject, that is, process, and object on the system. These types are defined by the SELinux
policy and are contained in security labels on the files themselves, stored in the
extended attributes (
xattrs) of the file. When a type is associated with a processes, the type is called a
domain, as in, "
httpd is in the domain of
httpd_t." This is a terminology difference leftover from other models when domains and types were handled separately.
All interactions between subjects and objects are disallowed by default on an SELinux system. The policy specifically allows certain operations. To know what to allow, TE uses a matrix of domains and object types derived from the policy. The matrix is derived from the policy rules. For example, allow httpd_t net_conf_t:file { read getattr lock ioctl }; gives the domain associated with httpd the permissions to read data out of specific network configuration files such as /etc/resolv.conf. The matrix clearly defines all the interactions of processes and the targets of their operations.
Because of this design, SELinux can implement very granular access controls. For Red Hat Enterprise Linux 4 the policy has been designed to restrict only a specific list of daemons. All other processes run in an unconfined state. This policy is designed to help integrate SELinux into your development and production environment. It is possible to have a much more strict policy, which comes with an increase in maintenance complexity.
The technical skills required for this guide are not very extensive. The most important skill to have is an ability to learn technical theories and put them into practice. It helps if you come into this guide with an idea of what you want to do, such as administrating a set of common services, making user content from /home/ served via Apache HTTP, manipulating policy to get a custom PHP Web application running, or writing a policy from to enable a custom application to be protected by SELinux. The following is helpful to have as you read through this guide:
-
Strong working understanding of Linux, especially Red Hat Enterprise Linux.
-
If you are going to be administrating services, manipulating or analyzing policy, junior- to mid-level system administration skills and experience is necessary, such as being a Red Hat Certified Technician (RHCT) or Red Hat Certified Engineer (RHCE)..
To work with SELinux at that level, you must have the following:
-
An understanding of traditional Linux/UNIX security.
-
An understanding of how a Linux/UNIX system operates on a lower-level, such as how the kernel has system calls for various operations (open, close, read, write, ioctl, poll, etc.) An understanding of programming and system theory is useful in writing policy.
-
A familiarity with the m4 macro language, which is helpful in understanding some parts of the SELinux policy.
-
Read many of the NSA papers, listed in .
-
Administrator privileges on the system you have Red Hat Enterprise Linux installed on is necessary to perform many of the operations in this guide. However, there is plenty of useful information for end-users.
-
Somewhere you can examine and work with the policy sources. This can be a test or development machine, or possibly a workstation. Many of the examples and explanations in this book assume that you have the system in front of you to explore while you read.
-
Some additional patience. SELinux is a different way of handling access control than many administrators and users are familiar with.
Information about Red Hat training can be obtained via .
There are two main directories for SELinux policy in /etc/selinux/:
It is possible to have more than one policy existing on the system, although only one may be loaded at a time. The policy binary files, and possibly source files, are located in /etc/selinux//, where is the name of your policy, such as targeted, strict, webhost, test, and so forth. The configuration file /etc/selinux/config defines which policy is used, for example SELINUXTYPE=targeted.
In this document, the convention of $DIRECTORY_TYPE is used instead of the full path to assist in readability:
-
The variable directory $SELINUX_SRC/ is a substitute for the generic directory of /etc/selinux//src/policy/ and the targeted policy source directory at /etc/selinux/targeted/src/policy/.
-
The variable directory $SELINUX_POLICY/ is a substitute for the generic directory of /etc/selinux//policy/ and the binary targeted policy directory at /etc/selinux/targeted/policy/.
An important file is the audit log file. In Red Hat Enterprise Linux, $AUDIT_LOG by default is /var/log/messages. However, this is configurable via /etc/syslog.conf, and future work on an audit daemon will handle kernel audit events and log them into a separate file. Because of the variable nature of where the audit logs are, the variable file $AUDIT_LOG is used as a substitute.
Other important files and directories include $SELINUX_POLICY/booleans and $SELINUX_POLICY/contexts/, which are both discussed in .
The most important file for SELinux is the binary policy file. This file is located at /etc/selinux/targeted/policy/policy.. The represents the two digits of the policy version. In the case of Red Hat Enterprise Linux 4, this file is policy.18.
more informations :
阅读(1182) | 评论(0) | 转发(0) |
