I have now got a Debian Xen domU running the strict SE Linux policy that can boot in enforcing mode. I expect that tomorrow I will have it working with full functionality and that I will be able to run another SE Linux Play Machine in the near future.
For more information on my work on security features in Debian read the full version of this post on my new blog.
Frank Mayer of Tresys has written a great article on the techtarget.com site about SE Linux.
It seems mostly aimed at managers and novice users and explains how SE Linux isn't really that difficult to use but is however a foundation technology that is needed for secure systems.
Check it out!
Today I gave three talks at my local LUG. The first was my latest SE Linux talk (I’ll put the notes online soon). The second was a talk about voting.
I asked for a show of hands, who has already decided which party they will vote for at the next federal election (about 12 people put their hands up). I then asked people to put their hands down if they were not a member of the party that they intend to vote for, including myself there were only two raised hands in the room (including mine)!
...
The final talk I gave was about getting speakers for Linux Users’ Groups.
The full post is here.
Jeff Waugh wrote an amusing post about SE Linux and GConf support. It's good to see SE Linux being promoted to the GNOME community.
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.
The online magazine EWeek has done a review of RHEL5. It's quite a positive review which can be summarised as "good support for Xen as service (not an appliance), better value than previous versions with the licenses for multiple guests included, and SE Linux briefly got in the way but the Troubleshooting tool fixed it quickly and easily".
The problem they had is that the SE Linux policy expects Xen images to be in /var/lib/xen/images, but the Xen configuration tools apparently didn't adequately encourage them to use that directory. They stored the images somewhere else and SE Linux stopped it from working. The Troubleshooting tool did something that they didn't describe and then it all worked.
Generally a very positive review of RHEL5 and a moderately positive review of SE Linux in RHEL5.
PS You might have to turn off JavaScript to view the link, the page has broken JavaScript code that takes an unreasonable amount of CPU time.
At http://tanso.net/selinux/ Jan-Frode Myklebust has documented his work in creating new SE Linux policy to run Googleearth on Red Hat Enterprise Linux 5. He discussed this with us on #selinux in irc.freenode.net (the main SE Linux IRC channel).
One of his later IRC comments was:
"erich" refers to Erich Schubert. His AppArmor blog entry is currently the top entry in his SE Linux list.
I posted the NSA paper titled The Inevitability of Failure on my source-dump blog at this URL. If you want to get the background to SE Linux then this is the paper to read.
Submitting big documents (62K) to Blogger turns out to be surprisingly painful. It's a pity that Blogger doesn't support editing sections (as MediaWiki does) so every edit requires that the entire document be transferred back and forth. Do other blog servers make this easier?
Karl MacMillan writes an interesting review of a Sun article about SE Linux. Not only does he correct errors in the Sun article but he also summarises some of the features of SE Linux design and terminology that we use. If you are interested in computer security and want to learn some of the basic concepts then Karl's review is worth reading.
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.
Debian is participating in the Google Summer Of Code (or Winter if you are in the southern hemisphere).
It would be good if we could get a SE Linux related project in. If you are interested in doing some SE Linux work (or other security related work) in this regard then please let me know. I'm interested in helping mentor for such projects.
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:
Then I used the following commands to create a policy module and package it:
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;
checkmodule -M -m -o local.mod local.teThe result was the object file local.pp and in intermediate file local.mod (which incidentally can be removed once the build is finished).
semodule_package -o local.pp -m local.mod
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.
While reading the discussion of Vista security on Bruce Schneier's blog it occurred to me that comparing the issues of DRM that face MS with the issues faced by SE Linux developers provides some benefits.
SE Linux is designed to enable the owner of a computer to effectively enforce security policies to protect their system integrity and the confidentiality of their data. Some of the SE Linux users (military users) use all the available features, but most people only use the targeted policy which provides a sub-set of the system integrity and data confidentiality protections that are available to give a greater ease of use.
Fedora and Red Hat Enterprise Linux ship with the SE Linux targeted policy enabled by default. This policy is not something that most users notice. The main program that is commonly used which might have an issue with the default SE Linux policy is Apache. Fedora and RHEL systems that do not run Apache (which is most of them) can run SE Linux with almost no costs.
setsebool -P httpd_disable_trans 1It seems clear to me that there is no good reason for disabling SE Linux by default. There are reasons for running a particular daemon in the unconfined_t domain via the FOO_disable_trans boolean. EG to run Apache without restrictions you would type the above commands.
/etc/init.d/httpd restart
A few days ago I installed Debian/Etch on my Thinkpad. One of the reasons for converting from Fedora to Debian is that I need to run Xen and Fedora doesn't support non-PAE machines with Xen. Ironically it's hardware supplied to me by Red Hat (Thinkpad T41p) that is lacks PAE support and forces me to switch to Debian. I thought about just buying a new dual-core 64bit laptop, but that seems a bit extravagant as my current machine works well for everything else.
Feeling adventurous I decided to use the graphical mode of the installer. I found it a little confusing, at each stage you can double-click on an item or click on the continue button to cause the action to be performed. The partitioning section was a little unclear too, but given that it has more features than any other partitioning system I've seen I wasn't too worried (options of creating a degraded RAID array and for inserting a LUKS encryption layer at any level are really nice). The option to take a screen-shot at any time was also a handy feature (I haven't yet inspected the PNG files to see what they look like).
Another nice feature was the way that the GUI restarts after a crash. While it was annoying that the GUI started crashing on me (and would have prevented a less experienced user from completing the install) the fact that it didn't entirely abort meant that I could work around the problem.
I have not yet filed any bug reports against the installer because I have not done a repeatable install (there is a limit to how much testing I will do on my most important machine). In the next few days I plan to do a few tests of the graphical installer on test hardware for the operations that are important to me and file appropriate bug reports. I encourage others to do the same, the graphical mode of the installer and the new encryption and RAID features are significant improvements to Debian and we want them to work well.
I have realised that it won't be possible to get SE Linux as good as I desire before the Etch release, even if the release is delayed again. I'm not sure how many fixes can go in after the release (I hope that we could move to a model similar to RHEL - but doubt that it will happen). So I now plan to maintain my own repository of Etch SE Linux packages and for other packages which need changes to make them work in the best possible manner with SE Linux. I will append something like ".se1" to the version of the packages in question, this means that they will be replaced if a security update is released for the official package. Apart from the SE Linux policy packages (for which any security updates will surely involve me) the changes I am going to make will not be major and will be of less importance than a security update.
I will also add other modified and new packages to my repository that increase the general security of Etch. Apart from SE Linux all the changes I intend to host will be minimal cost issues (IE they won't break things or increase the difficulty of sys-admin tasks), and the SE Linux related changes will not break anything on non-SE systems. So someone who wants general security improvements without using SE Linux might still find my repository useful.
checkmodule -m -o local.mod local.te
semodule_package -o local.pp -m local.mod
semodule -u local.pp
module local 1.0;
require {
class chr_file { read write };
class fd use;
type restorecon_t;
type tmpfs_t;
type initrc_t;
type semanage_t;
role system_r;
};
allow restorecon_t tmpfs_t:chr_file { read write };
allow semanage_t initrc_t:fd use;
Following from my 5 minute OSDC talk yesterday on 5 security improvements needed in Linux distributions I gave a 5 minute talk on installing SE Linux on Debian etch. To display the notes I formatted them such that they were in 24 line pages and used less at a virtual console to display them. The ultra-light laptop I was using has only 64M of RAM which isn't enough for a modern X environment and I couldn't be bothered getting something like Familiar going on it.
After base install you install the policy and the selinux-basics package:
# apt-get install selinux-basics selinux-policy-refpolicy-targeted
The following extra packages will be installed:
checkpolicy libsemanage1 mime-support policycoreutils python python-minimal
python-selinux python-semanage python-support python2.4 python2.4-minimal
selinux-utils
Suggested packages:
python-doc python-tk python-profiler python2.4-doc logcheck syslog-summary
The following NEW packages will be installed:
checkpolicy libsemanage1 mime-support policycoreutils python python-minimal
python-selinux python-semanage python-support python2.4 python2.4-minimal
selinux-basics selinux-policy-refpolicy-targeted selinux-utils
0 upgraded, 14 newly installed, 0 to remove and 0 not upgraded.
Need to get 6362kB of archives.
After unpacking 41.5MB of additional disk space will be used.
Do you want to continue [Y/n]?
# fixfiles relabel
Files in the /tmp directory may be labeled incorrectly, this command
can remove all files in /tmp. If you choose to remove files from /tmp,
a reboot will be required after completion.
Do you wish to clean out the /tmp directory [N]? y
Cleaning out /tmp
/sbin/setfiles: labeling files under /
matchpathcon_filespec_eval: hash table stats: 14599 elements, 14245/65536 buckets used, longest chain length 2
/sbin/setfiles: labeling files under /boot
matchpathcon_filespec_eval: hash table stats: 19 elements, 19/65536 buckets used, longest chain length 1
/sbin/setfiles: Done.
title Debian GNU/Linux, kernel 2.6.17-2-686
root (hd0,1)
kernel /vmlinuz-2.6.17-2-686 root=/dev/x selinux=1 audit=1 ro enforcing=1
initrd /initrd.img-2.6.17-2-686
# id -Z
system_u:system_r:unconfined_t
# ps axZ |grep -v unconfined_t|grep -v kernel_t|grep -v initrc_tThe initial install of policy inserts modules to match installed software, if you install new software then you need to add new modules with the semodule command:
LABEL PID TTY STAT TIME COMMAND
system_u:system_r:init_t 1 ? Ss 0:02 init [2]
system_u:system_r:udev_t 1999 ? S.s 0:01 udevd --daemon
system_u:system_r:syslogd_t 3306 ? Ss 0:00 /sbin/syslogd
system_u:system_r:klogd_t 3312 ? Ss 0:00 /sbin/klogd -x
system_u:system_r:apmd_t 3372 ? Ss 0:00 /usr/sbin/acpid -c /etc
system_u:system_r:gpm_t 3376 ? Ss 0:00 /usr/sbin/gpm -m /dev/i
system_u:system_r:crond_t 3402 ? Ss 0:00 /usr/sbin/cron
system_u:system_r:local_login_t 3423 tty1 Ss 0:00 /bin/login --
system_u:system_r:local_login_t 3424 tty2 Ss 0:00 /bin/login --
system_u:system_r:getty_t 3425 tty3 Ss+ 0:00 /sbin/getty 38400 tty3
system_u:system_r:getty_t 3426 tty4 Ss+ 0:00 /sbin/getty 38400 tty4
system_u:system_r:getty_t 3429 tty5 Ss+ 0:00 /sbin/getty 38400 tty5
system_u:system_r:getty_t 3430 tty6 Ss+ 0:00 /sbin/getty 38400 tty6
system_u:system_r:dhcpc_t 3672 ? S.s 0:00 dhclient3 -pf /var/run/
# semodule -i /usr/share/selinux/refpolicy-targeted/apache.pp
security: 3 users, 7 roles, 824 types, 67 bools
security: 58 classes, 11813 rules
audit(1165532434.664:21): policy loaded auid=4294967295
# semodule -i /usr/share/selinux/refpolicy-targeted/bind.pp
security: 3 users, 7 roles, 836 types, 68 bools
security: 58 classes, 12240 rules
audit(1165532467.874:22): policy loaded auid=4294967295
# restorecon -R -v /etc /usr/sbin /var/run /var/log
restorecon reset /etc/bind context system_u:object_r:etc_t->system_u:object_r:named_zone_t
restorecon reset /etc/bind/named.conf context system_u:object_r:etc_t->system_u:object_r:named_conf_t
[...]
restorecon reset /etc/apache2 context system_u:object_r:etc_t->system_u:object_r:httpd_config_t
restorecon reset /etc/apache2/httpd.conf context system_u:object_r:etc_runtime_t->system_u:object_r:httpd_config_t
[...]
restorecon reset /usr/sbin/named context system_u:object_r:sbin_t->system_u:object_r:named_exec_t
restorecon reset /usr/sbin/apache2 context system_u:object_r:sbin_t->system_u:object_r:httpd_exec_t
restorecon reset /usr/sbin/rndc context system_u:object_r:sbin_t->system_u:object_r:ndc_exec_t
restorecon reset /usr/sbin/named-checkconf context system_u:object_r:sbin_t->system_u:object_r:named_checkconf_exec_t
[...]
restorecon reset /var/run/bind context system_u:object_r:var_run_t->system_u:object_r:named_var_run_t
restorecon reset /var/run/bind/run context system_u:object_r:var_run_t->system_u:object_r:named_var_run_t
restorecon reset /var/run/bind/run/named.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:named_var_run_t
restorecon reset /var/run/motd context system_u:object_r:initrc_var_run_t->system_u:object_r:var_run_t
restorecon reset /var/run/apache2 context system_u:object_r:var_run_t->system_u:object_r:httpd_var_run_t
restorecon reset /var/run/apache2/cgisock.3558 context system_u:object_r:var_run_t->system_u:object_r:httpd_var_run_t
restorecon reset /var/run/apache2.pid context system_u:object_r:initrc_var_run_t->system_u:object_r:httpd_var_run_t
restorecon reset /var/log/apache2 context system_u:object_r:var_log_t->system_u:object_r:httpd_log_t
restorecon reset /var/log/apache2/error.log context system_u:object_r:var_log_t->system_u:object_r:httpd_log_t
restorecon reset /var/log/apache2/access.log context system_u:object_r:var_log_t->system_u:object_r:httpd_log_t
# killall -9 apache2
# /etc/init.d/apache2 start
Starting web server (apache2)....
# /etc/init.d/bind9 restart
Stopping domain name service...: bind.
Starting domain name service...: bind.
system_u:system_r:httpd_t 3833 ? Ss 0:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t 3834 ? S 0:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t 3839 ? Sl 0:00 /usr/sbin/apache2 -k start
system_u:system_r:httpd_t 3841 ? Sl 0:00 /usr/sbin/apache2 -k start
system_u:system_r:named_t 3917 ? Ssl 0:00 /usr/sbin/named -u bind
Today I discovered a bug in one of my programs, it called system() and didn't correctly escape shell eta-characters. Fortunately I had written custom SE Linux policy for it which did domain_auto_trans(foo_t, shell_exec_t, very_restricted_t) so there was no possibility of damage.
The log files (which were not writable by the daemon by both SE Linux access control and Unix permissions) indicated that no-one had attempted to exploit the bug.
Here's an interesting blog entry comparing SE Linux and AppArmor. It has some amusing comments, one of which I used for the title of this entry.
There are two things I don't like about AppArmor. One is that it doesn't label Inodes but instead bases it's access control on file names. This means that renaming a file may change the access granted to it, and a file with multiple hard links may have different sets of access granted to each name. The hard link problem is a killer, imagine that name A grants execute access to the file and name B grants write access, therefore you have the ability to create an executable file.
The other thing I don't like about AppArmor is that it's goals are low. The current implementation of AppArmor can be compared to the SE Linux targeted policy. The difference is that AppArmor is currently achieving everything that it was designed to do while the targeted policy is intentionally providing less security features to give greater ease of use. There is a well defined transition path from targeted to strict, and from strict to MLS. There is no transition path from the current AppArmor implementation to something better.
Rumor has it that Suse have bought the rights to a MLS system and that they want to get LSPP certification. LSPP certification requires that access control be based on Inodes not file names (IE renaming a file may not change the access that is granted to it). It will be interesting to see how they integrate AppArmor and a MLS system.
