I just received a question about SE Linux via email. As I don’t want to post private messages containing material that’s globally useful I’ll answer through my blog:

> other than strict and targeted policies……other policies like
> RBAC, MCS, Type Enforcement are also there….how are these policies
> implemented

The two main policies are the strict policy and the targeted policy. The strict policy is the earliest and was originally known as the sample policy (but was given the name “strict” after targeted was developed).

The strict policy aims to give minimal privileges to all daemons. The targeted policy aims to restrict the programs that are most vulnerable (network facing daemons) and not restrict other programs (for ease of use). There is currently work in progress on combining those policies so the person who compiles the policy can determine which features of strict they desire.

RBAC means Role Based Access Control. The strict policy assigns users to roles and the role then limits the set of domains that can be entered. For example the user_r role does not permit the sysadm_t domain so a user who is only permitted to enter the user_r role can not perform sys-admin tasks. Like many terms RBAC is used in different manners, some people consider that it means direct control by role (EG role user_r can not write to /dev/hda), while SE Linux has a more indirect use of roles (role user_r can not run programs in domain sysadm_t or any other domain that allows writing to type fixed_disk_device_t – the type for /dev/hda). You may consider that the strict policy supports RBAC depending on which definition of the term you use.

Generally the targeted policy is not considered to support RBAC, although if you consider a role to merely be a container for a set of accesses that are permitted then a SE Linux domain could be considered a in the RBAC sense. I don’t think of targeted policy as being a RBAC implementation because all user sessions run in the domain unconfined_t which has no restriction. I think that to be considered RBAC a system must confine user logins.

Type enforcement is the primary access control mechanism for SE Linux. Every object that a process may access (including other processes) has a type assigned to it. The type of a process is known as a domain. The system has a policy database which for every combination of domain, type, and object class (which is one of dir, file, blk_file, etc – all the different types of object that a process may access) specifies whether the action is permitted or denied (default deny) and whether it is audited (default is to audit all denied operations and not audit permitted operations).

MCS is a confidentiality protection mechanism where each file has a set of categories assigned to it. The set may be empty, may contain all 1024 categories, or any sub-set. Each process has a set of categories that determines which files it may access. File access is granted if Unix permissions allow it, if the domain-type model allows it, and if MCS allows it (on an MCS system). I have just had an article on MCS published in Linux Journal.

MCS is an optional feature for people compiling Linux from source or for distribution vendors. For Red Hat Enterprise Linux, Fedora, and Debian the decision was made to include it, so the strict and targeted policies for those distributions include MCS.

There is another policy known as MLS. This is a policy build that comprises the strict policy plus Multi-Level Security. Multi-Level Security aims to give the highest confidentiality protection and comply with the LSPP (Labeled Security Protection Profile – roughly comparable to B1) Common Criteria certification. It would be possible to build a targeted policy with MLS but that wouldn’t make sense – why have the highest protection of confidentiality with anything less than the highest protection of integrity?

As for how the policies are implemented, I’m not about to write a tutorial on policy writing for a blog post, I’m sure that someone will post a link to a Tresys or Fedora web page in the comments. ;)

> there r some packages of linux in which some changes has been made
> to support linux……for eg:- coreutils, findutils

That is correct. Every program that launches a process on behalf of a user at a different privilege user (EG /bin/login, sshd and crond) and every program that creates files for processes running in different domains (EG logrotate creating new log files for multiple daemons) needs to be modified to support SE Linux. Also ls and ps were modified to show SE Linux contexts as well as the obvious programs in coreutils.

> ‘Z’ is the new thing that have been added to most of the
> utilities……wherever I search I get the changes made only in few
> utilities like ps, mv, cp, ls
>
> Can u help me by giving all the changes made in each of the utilities…..

Unfortunately I can’t. This has been identified as an issue and there is currently work in progress to determine the best way of managing this.

The book SE Linux by Example has been reviewed on Slashdot.

The issue of Perl scripts was raised for discussion. It is of course true that a domain which is permitted to run the Perl interpreter can perform arbitrary system calls – it can therefore do anything that SE Linux permits that domain to do. This is in fact a demonstration of how SE Linux does the right thing! If you want to restrict what can be done when executing the Perl interpreter then you can have a domain_auto_trans() rule to have Perl run in a different domain.
Restricting Perl (as used by one particular program) is actually easier than restricting a complex application run by users such as Firefox. Users want to use Firefox for web browsing, local HTML file browsing, saving files that are downloaded from the web, running plugins, and more. Granting Firefox access to perform all those tasks means that it is not restricted from doing anything that the user can do.

A claim was made that a novice users would not understand how to use SE Linux. The fact is that they don’t need to. I know many novice computer users who are running SE Linux systems, it just works! It’s more advanced users that have to learn about SE Linux because they configure their machines more heavily.

The essential difference between path-based access control and Inode based access control is that the standard Unix commands to control file access (chmod, chown, and chgrp) all operate on Inodes. If a file has 1000 hard links then I can restrict access to all of them via a single chmod or chcon (the SE Linux command that is comparable to chmod) command. AppArmor does things differently and implements an access control model that is vastly different to the Unix traditions. SE Linux extends the Unix traditions with Mandatory Access Control.

Granting different levels of access to a file based on the name of the link which is used is a horror not a feature.

I wrote this as a blog entry rather than a /. comment because my lack of Karma means that less people will read my /. comments than my blog.

Creating a simple SE Linux policy module is not difficult.

audit(1173571340.836:12855): avc: denied { execute } for pid=5678 comm=”spf-policy.pl” name=”hostname” dev=hda ino=1234 scontext=root:system_r:postfix_master_t:s0 tcontext=system_u:object_r:hostname_exec_t:s0 tclass=file

For example I had a server with the above messages in the kernel message log from the spf-policy program (run from Postfix) trying to run the “hostnme” program. So I ran the following command to generate a .te file (SE Linux policy source):

dmesg|grep spf.policy|audit2allow -m local > local.te

The -m option to audit2allow instructs it to create a policy module. The local.te file is below:

module local 1.0;

require {
      class file execute;
      type hostname_exec_t;
      type postfix_master_t;
      role system_r;
};

allow postfix_master_t hostname_exec_t:file execute;

Then I used the following commands to create a policy module and package it:

checkmodule -M -m -o local.mod local.te
semodule_package -o local.pp -m local.mod

The result was the object file local.pp and in intermediate file local.mod (which incidentally can be removed once the build is finished).

After creating the module I used the following command to link it with the running policy and load it into the kernel:

semodule -i ./local.pp

Ulrich Drepper has written a good web page about text relocation which is most often noticed as execmod failures reported when running SE Linux. When an AVC message reports a failure of execmod against a shared object it means that the object has text relocations (the shared object code writes to code that it executes to fix up addresses). This is due to being compiled without -fPIC or -fpic.

The command eu-findtextrel (from the elfutils package) when run with a parameter of the shared object in question will tell you which functions were compiled without -fpic or -fPIC.

The module in question must be recompiled with -fpic or -fPIC to generate the correct code.

Without SE Linux it’s still a bug to compile a shared object without position independent code, so any shared object which can’t run under SE Linux because of execmod will probably have problems in other situations anyway (maybe only on certain architectures).

The issue of core file management has come up for discussion again in the SE Linux list.

I believe that there are two essential security requirements for managing core files, one is that the complete security context of the crashing process is stored (to the greatest possible extent), and the other is that processes with different security contexts be prevented from discovering that a process dumped core (when attacking a daemon it would be helpful to know when you made one of it’s processes dump core).

The core file will have the same UID and GID as the process that crashed. It’s impossible to maintain the complete security context of the crashing process in this manner as Unix permissions support multiple supplementary groups and Unix filesystems only support one GID. So the supplementary groups are lost.

There is also a sysctl kernel.core_pattern which specifies the name of the core file. This supports a number of modifiers, EG the value “core.%p.%u.%g” would give a file named “core.PID.UID.GID“. It would be good to have a modification to the kernel code in question to allow the SE Linux context to be included in this (maybe %z).

To preserve the SE Linux context of the crashing process with current kernel code we need to have a unique type for each process that dumps core, this merely requires that each domain have an automatic transition rule for creating files in the directory chosen for core dumps. In the default configuration we have core files dumped in the current directory of the process. This may be /tmp or some other common location which allows an attacker to discover which process is dumping core (due to the directory being world readable) and in the case of SE Linux there may be multiple domains that are permitted to create files in /tmp with the same context which gets in the way of using such a common directory for core files.

The traditional Unix functionality is to have core files dumped in the current directory. Obviously we can’t break this by default. But for systems where security is desired I believe that the correct thing to do is to use a directory such as /var/core for core files, this can be easily achieved by creating the directory as mode 1733 (so that any user can create core files but no-one but the sys-admin can read them) and then setting the core_pattern sysctl to specify that all core files go in that directory. The next improvement is to have a poly-instantiated directory for /var/core such that each login user has their own version. That way the user in question could see the core files created by their own processes while system core files and core files for other users would be in different directories. Poly-instantation is easier to implement for core files than it is for /tmp (and the other directories for which it is desirable) because there is much less access to such a directory. When things operate correctly core files are not generated, and users never need to access each other’s core files directly (they are mode 0600 so this isn’t possible anyway).

This area will require a moderate amount of coding before it works in the ideal manner. I aim to briefly describe the issues only in this post.