I have just read the Presentation Zen blog post about PowerPoint.

One of the interesting suggestions was that it’s not effective to present the same information twice, so you don’t have notes covering what you say. Having a diagram that gives the same information is effective though because it gives a different way of analyzing the data. I looked at a couple of sets of slides that I have written and noticed that the ratio of text slides to diagram slides was 6:1 and 3:1 in favor of text, and that wasn’t counting the first and last slides that have the title of the talk and a set of URLs respectively.

So it seems that I need more and better diagrams. I’ll include most of the diagrams I use in my current SE Linux talks in this post with some ideas on how to improve them. I would appreciate any suggestions that may be offered (either through blog comments or email).

The above diagram shows how the SE Linux identity limits the roles that may be selected, and how the role limits the domains that may be entered. Therefore the identity controls what the user may do and in this example the identity “root” means that the user has little access to the machine (a Play Machine configuration). I think that the above is reasonably effective and have been using it for a few years. I have considered a more complex diagram with the “staff_r” role included as well and possibly including the way that “newrole” can be used to change between roles. So I could have the above as slide #1 about identities and roles with a more detailed diagram following to replace a page of text about role transition.

The above diagram shows the domain transitions used in a typical system boot and login process. It includes the names of the types and a summary of the relevant policy rules used to implement the transitions. I also have another diagram that I have used which is the same but without the file types and policy. In the past I have never used both in the one talk – just used one of the two and had text to describe the information content of the other. To make greater use of diagrams I could start with the simple diagram and then have the following slide have all the detail.

The above diagram simply displays the MCS security model with ellipses representing processes and rectangles representing files.

The above diagram shows a simplified version of the MMCS policy. With MMCS each process has a range with the low level representing the minimum category set of files to which it is permitted to write and the high level representing the files that it may read and write. So to write to a file with the “HR” category the process must have a low level that’s no higher than “HR” and a high level that is equal or greater than “HR“. The full set of combinations of two categories with low and high levels means 10 different levels of access for processes which makes for a complex diagram. I need something other than plain text for this but the above diagram is overly complex and a full set is even more so. Maybe a table with process contexts on one axis, file contexts on another and access granted being one of “R“, “RW” or nothing?

I also have a MLS diagram in the same manner, but I now think it’s too awful to put on my blog. Any suggestions on how to effectively design a diagram for MLS? For those of you who don’t know how MLS works the basic concept is that every process has an “Effective Clearance” (AKA low level) which determines what it can write, it can’t write to anything below that because it might have read data from a file at it’s own level and it can’t read from a level higher than it’s own level. MLS also uses a high level for ranged processes and filesystem objects (but that’s when it gets really complex).

This last one is what I consider my most effective diagram. It shows the benefits of SE Linux in confining daemons in a clear and effective manner. Any suggestions for improvement (apart from fixing the varying text size which is due to a bug in Dia) would be appreciated.

The above diagrams are all on my SE Linux talks page, along with the Dia files that were used to create them. They may be used freely for non-commercial purposes.

If anyone has some SE Linux diagrams that they would like to share then please let me know, either through a blog comment, email, or a blog post syndicated on Planet SE Linux.

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