Multi-Category Security in SELinux in Fedora Core 5
Listing 1. Example of Using semanage
# semanage user -a -P user -R user_r -L s0:c1 -r s0:c1-SystemHigh rjc # semanage user -l Labeling MLS/ MLS/ SELinux User Prefix MCS Level MCS Range SELinux Roles rjc user s0:c1 s0:c1-SystemHigh user_r root user s0 SystemLow-SystemHigh system_r sysadm_r +user_r system_u user s0 SystemLow-SystemHigh system_r user_u user s0 SystemLow-SystemHigh system_r sysadm_r +user_r
Fedora Core 5 uses the low end of the range for a process to specify the default context of files. The range parameter is specified by the -r switch. When using Fedora Core 5, often the only significant part of the range is the high end, which specifies the access. You should use the parameters -P user -R system_r when creating a user with the targeted policy (which is the default policy for a Fedora Core 5 install). The strict policy is much like the targeted policy in terms of MCS. Most of this article applies to the strict policy, although the -P and -R options to the semanage command will need different parameters.
After adding an identity, you must add a login entry to assign a UNIX account to the identity. The login configuration also allows you to specify the MCS range, because you may have many UNIX accounts with the same SELinux identity that have different MCS ranges assigned to them when they log in. You must use the -s parameter to specify the name of an SELinux identity that already exists. If you do not use the -r option to specify the range, it defaults to using no categories for the login entry in question (which may not be valid, depending on the low level of the range for the identity).
Below is an example of adding a login entry:
# semanage login -a -s rjc -r s0:c1-SystemHigh rjc # semanage login -l Login Name SELinux User MLS/MCS Range __default__ user_u s0 rjc rjc s0:c1-SystemHigh root root SystemLow-SystemHigh
Note that the range for a login entry must be a subset of the range for an SELinux user identity. This means the low end of the login range must not be lower than the low end of the user identity range, and the high end of the login range must not be higher than the high end of the user identity range. In most cases, you will create a login entry with the same range as the user identity, so this won't be a problem.
After creating a file, it is possible to change the label to a different level with the chcon -l command. Below is an example of how to use it:
$ touch foo $ ls -lZ foo -rw-r--r-- rjc rjc rjc:object_r:tmp_t foo $ chcon -l s0:c0 foo $ ls -lZ foo -rw-r--r-- rjc rjc rjc:object_r:tmp_t:ProjectA foo
Note that the level s0:c0 was translated to ProjectA; that is the translation I created previously.
It is possible to run a process with a different range. The following is an example of the use of the id -Z command to display the SELinux context (including the MCS range at the end) as well as the use of the runcon -l command to run an instance of bash in a different range:
$ id -Z rjc:system_r:unconfined_t:SystemLow-SystemHigh $ runcon -l s0-s0:c10.c20 bash $ id -Z rjc:system_r:unconfined_t:s0-s0:c10.c20 $ runcon -l s0-s0:c9.c20 bash execvp: Permission denied
MLS was implemented in a flexible manner via the policy language. This allowed us to develop the MCS policy afterward using the same language features and also permits the development of other category- and level-based confidentiality controls without changing kernel code. One example of this is my new development, Mandatory MCS (MMCS).
A Mandatory Access Control (MAC) system is a system where the access control is determined by the system administrator and enforced by the operating system. Users are not permitted to override this access control by granting excess access to their own data files. In UNIX permissions, it is possible to create a mode 777 file in the /tmp directory that grants full access to all users. With MMCS, I wanted to prevent such access being granted. In the MMCS policy, it is not permitted to write to a file with a level below the low level of the process. This means that by setting the low levels for a user, the administrator can determine the minimum access needed to read files created by that user.
MCS and MLS policies have several significant differences. In MLS, the access is based on the low level of the range (the effective clearance) with the high level of the range used mostly to determine the access via the newrole program. In MCS, the access for both reading and writing is based on the high level of the range with the low level used only for restricting write access. Another difference is that MCS is designed to protect only the contents of files, while MLS restricts all methods of data transfer. Another major difference is that in MCS, a process may launch a child with a different range with minimal restrictions.
Russell Coker has worked on Security-Enhanced Linux (SELinux) since 2001. He is an independent consultant specializing in SELinux and ISP administration.
|Play for Me, Jarvis||Apr 16, 2015|
|Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites||Apr 15, 2015|
|Non-Linux FOSS: .NET?||Apr 13, 2015|
|Designing Foils with XFLR5||Apr 08, 2015|
|diff -u: What's New in Kernel Development||Apr 07, 2015|
- Drupageddon: SQL Injection, Database Abstraction and Hundreds of Thousands of Web Sites
- Play for Me, Jarvis
- Non-Linux FOSS: .NET?
- Designing Foils with XFLR5
- Not So Dynamic Updates
- Flexible Access Control with Squid Proxy
- New Products
- Users, Permissions and Multitenant Sites
- diff -u: What's New in Kernel Development