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.
Practical Task Scheduling Deployment
July 20, 2016 12:00 pm CDT
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.Register Now!
- Interview with Patrick Volkerding
- Google's SwiftShader Released
- SUSE LLC's SUSE Manager
- My +1 Sword of Productivity
- Tech Tip: Really Simple HTTP Server with Python
- SuperTuxKart 0.9.2 Released
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Non-Linux FOSS: Caffeine!
- Returning Values from Bash Functions
- Managing Linux Using Puppet