Revision as of 16:37, 24 May 2008

Discussion of Policies

SELinux is a very flexible architecture. You can pick and choose your policy, depending on your security needs.

During the development of SELinux, we have published three different types of policy so far: targeted, strict, and MLS. The original policy published at the NSA was the strict policy. Its goal was to lock down the entire operating system, controlling not only the daemons that live in system space, but controlling the user space as well. Strict policy has the most domains, and adds the largest burden on users.

Strict

During the development of Fedora Core 2, we attempted to use strict policy as the default policy. We had multiple problems with this because strict policy was governing the way that users were running their systems. We had to cover all possible ways that a user would be able to setup their system. As you can imagine we had a ton of problems and bug reports. Most people when confronted with SELinux at that time, just wanted it turned off.

Strict policy works best where you have a controlled userspace. For example, you can setup a security policy where your users are only allowed to use the Web browser to view files on the Internet and only allowed to download to certain directories. You could limit what applications the Web browser can launch to helper applications.

Targeted

After our experiences with the strict policy, we went back and reflected on what our goals were. We wanted a system where the user was protected from System applications that were listening on the network.

These applications were the doors and windows where the hackers would enter the system. So we decided to target certain domains and lock them down, while continuing to leave userspace to run in an unconfined nature. Targeted policy was born. In Fedora Core 3 we targeted about 10 domains for lock down and came up with a new domain called unconfined_t.

Processes within the domain of unconfined_t would have the same access to the system as if SELinux was not enabled. We shipped this policy and this was the basis for Red Hat Enterprise Linux 4. In Fedora Core 4 and beyond we have continued to add new targets to the point where most of system space has been locked down, but userspace is still running in the unconfined_t domain.

In Fedora Core 5 we have begun experimenting with locking down some of unconfined_t by eliminating the execmem, execheap, execstack, and execmod privs whereever possible.

During the development of Fedora Core 5/Red Hat Enterprise Linux 5, we have developed a new policy, for servers only.

The goal of this policy is to allow a Linux operating system to get EAL4+/LSPP certification. It is the first operating system to combine the Bell And LaPadula model and Type Enforcement . In developing this policy, we have turned on the fourth field of the security context, the security or sensitivity level. This allows us to start the handling of labeled files.

The policy contains rules that not only govern what security types are able to do, but also what they can do when running at a particular security level. In MLS there are two componants of the Security Level, the sensitivity level, which can go from s0-s15, and the capabilities, which can go from c0 - c255. We also added MCS policy to targeted and strict, which confines the sensitivity level to s0 but allows us to work with user defined capapabilites. This allows us to use several new features in the OS and test them out without putting the burden of MLS on all users.