From Fedora Project Wiki
No edit summary
Line 2: Line 2:


SELinux is a very flexible architecture.  You can pick and choose your policy, depending on your security needs.
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 four different types of policy so far:  targeted, strict, minimum 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
* Targeted

Revision as of 23:54, 19 January 2010

Discussion of Policies

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

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

The ovirt team was looking for a minimal policy to run on low memory machines platforms, that only confines virtual machines. ovirt does not run any of the services confined by targeted policy so they did not want to overhead of having those policies on the machine. Similarly people are experimenting with using SELinux on "devices" like smart phones. What policy do we have for them?

In Fedora 10 we introduced selinux-policy-minimum. Minimum policy is built exactly the same as targeted policy, but installs ONLY the base policy package and the unconfined.pp. All of the SELinux policy modules from the targeted policy are in the selinux-policy-minimum RPM package but they are not compiled and loaded into the kernel in the post install.

Pretty much everything on this system runs as initrc_t or unconfined_t so all of the domains are unconfined.