|
|
楼主 |
发表于 2004-11-20 08:09:13
|
显示全部楼层
Overview of SELinux
SELinux, is a Mandatory Access Control (MAC) security system for Linux based on the domain-type model. It was written by the NSA (http://www.nsa.gov/selinux/) and is comprised of a kernel module (included in all 2.6 kernels), patches to certain security related applications, and a security policy.
The standard Unix security model is known as Discretionary Access Control (DAC). This means that every program has full control over all access to its resources. If it chooses to put files in /tmp/ that contain potentially secret data and makes them world readable then there is nothing to stop it! MAC is fundamentally different in that the system security policy has full control over the access that is granted to each resource. The MAC implementation in SELinux allows a program to create a file in /tmp/ with world read access according to Unix permissions, but after the Unix permission checks are applied the SELinux permission checks determine whether access to a file is granted. Among other security measures, this means that if a file has Unix permission mode 0777 you may still be refused access to read, write, or execute it. With only DAC, any program run by the user can leak or modify the contents of any file that the user has access to. SELinux permits restricting which files each process can access and what level of access is to be granted. This means that if a program is using secret data then it can be prevented from writing to any files that less privileged programs can read.
SELinux allows more fine grained access controls than traditional Unix permissions offer. For example, the administrator can permit an application to append data to a log file but not re-write or truncate it. Ext2 and ext3 file systems have an append-only flag that can be set by chattr(1), but this is for all access to the file (it can not be append-only for one process and fully writable for another). Also an application can be permitted to create files and write data to them but not delete existing files with the same permission in the same directory: this variation on append-only files can not be done in a stock Linux kernel without SELinux. Network programs can be permitted to bind to the port or ports that they need (for example, port 53 for BIND) but denied bind access to other ports.
The domain-type model means that every process runs in a security domain, and every resource (file, directory, socket, etc.) has a type associated with it. There is a set of rules listing the actions that each domain may perform on every type. One advantage of the domain-type model is that the policy can be analyzed to determine which information flows are possible. In standard Unix, users can usually view each other's processes with the ps command, which can give valuable information to an attacker. Even if wide ps access is blocked, there are still many possible ways for data to be accidentally or intentionally leaked, and there is no way of determining which information flows might be permitted on a given Unix configuration. There are tools to analyze SELinux policy and determine which data flows are possible. For example, if two applications are granted append access to a file type that is used for log files, they have no direct method of communication. If one of the applications is granted read access as well then there is a possibility of one-way communication.
One example of the benefits of analyzing the policy is the restriction on access to /etc/shadow. In a strict configuration of the Fedora SELinux policy in Fedora Core 3, there are 17 domains which are permitted access to the type shadow_t (used for /etc/shadow), and only 9 of them have write access. Of these 17 domains only two can be entered from a user domain, one is for /usr/bin/passwd, and the other is for /sbin/unix_chkpwd (a helper program for screen blankers and other unprivileged programs to perform a password check). Some of those 17 domains are for programs that are not used on most systems (for example, the domain radius_t for RADIUS servers), so therefore any machine which does not have a RADIUS server installed has at most 16 accessible domains which can access /etc/shadow! Note that the Fedora policy is getting more tunable options; future versions of the policy may allow more than 17 domains to access /etc/shadow depending on the tunable options selected. Also note that this number is based on the strict policy with the most strict options. A default install allows more access.
On a non-SE machine every process that runs as root can access /etc/shadow. This means that any security problem in any binary that is SETUID root or in any network daemon which runs as root is catastrophic. SELinux allows us to restrict daemons to the access that they need. BIND can only provide a service on port 53, DHCP servers have raw network access, and DHCP clients have raw network access and can change local interfaces. But none of those programs can access /etc/shadow, /home, /root, or other significant resources. So on SELinux if BIND is compromised, the worst it can do is send out bogus DNS packages. If DHCPD is compromised, the worst it can do is mess up your IP address assignment. This is much better than a remote root exploit!
Now, obviously programs can invoke other programs. In this case, DHCPD might try to invoke /sbin/unix_chkpwd manually to perform a brute-force password attack, for example. But even that potential vulnerability is closed: SELinux has the ability to specify “transition” rules, which determine which domains can enter other domains. In this case, a screen saver invoked on a local user’s behalf might be allowed to transition into the privileged domain for /sbin/unix_chkpwd, but that transition is denied to DHCPD.
These limitations give you assurances about the state of the system. If your DHCP server is discovered to be a buggy version, then all you have to do is install the fixed one and make sure that all clients have the right IP addresses. On a non-SE system you would be left wondering whether an attacker had taken over your system and hidden their tracks.
SELinux provides strong separation between domains. I ran a Debian machine with an open root password for two years, and I have now run a Fedora Core machine with an open root password for several months. They have withstood many attempts to crack them as root. Refer to http://www.coker.com.au/selinux/play.html for details if you would like to try logging in to them. There are also links to sites containing information on SELinux play machines running Debian and Gentoo. Be aware that when logging in to such a machine the same root account is shared by other people who may be hostile to you. It would be most unwise to log in to such a machine with X11 or SSH agent forwarding turned on or to send any data to such a machine that you regard as secret. Do not log in to such a machine and then ssh to another machine! If you do not feel confident in your ability to deal with these issues, then it may be best to avoid using the play machines. Note that I run my Fedora Core SELinux play machine in my spare time on hardware that I own. It is not an official Red Hat service.
Note that play machines aren't always running, it takes time to monitor such a machine, and they get turned off when the owner is busy.
Fedora Core 2 was released with integrated SELinux support (although disabled by default). This is used as a test of the code that will be released in Red Hat Enterprise Linux (RHEL) 4. However there will be some minor differences. The plan is that RHEL will have a default policy that is slightly more restrictive than Fedora Core because we believe that is what users will want. The plan is that future versions of Fedora Core will also have more restrictive policy than Fedora Core 2, but still less restrictive than RHEL. |
|
IP卡
狗仔卡
发表于 2004-11-20 08:05:54
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
显身卡
bject_r:user_games_rw_t to rjc