SE Linux is like a moat filled with sharks with laser attached head gear

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.

Debian SE Linux

Yesterday Erich Schubert blogged about reducing Debian SE Linux work due to lack of hardware. To solve such problems I’ve put a Debian/unstable machine on the net and given Erich the root password. Also now I am starting work on Debian SE Linux again too. There should be some significant developments in Debian SE Linux in the near future.

Also if anyone else has a problem of a lack of hardware getting in the way of free software development the first thing to do is to mention it on the IRC channel for the project in question. While Erich has demonstrated that blogging works, IRC is faster.

planet debian, spam, and SE Linux

In regard to my post yesterday about Planet Debian I received the following response:
James Purser said I’m betting that your feed is an atom feed. We had the same problem on PLOA with Jeff and Pias feeds when they switched to atom. Planet needs to be upgraded.
Well I am using an atom feed, so this probably explains it. Sorry for the inconvenience to the Planet Debian readers, I guess that things will stay the way they are until it is upgraded.

Also when viewing my blog entry in Planet Debian I realised that much of a spam message had got pasted in to the URL field for the Planet Debian link. Oh the irony that I only found this embarassing error because of a bug in the Planet software.

This brings me to another issue, Security Enhanced X. With SE-X (before you ask, I didn’t invent the acronym) you can use SE Linux to control communication between windows on an X desktop. With a modification to the clipboard manager (klipper in the case of KDE) every piece of data that’s copied from an application will have a security context assigned to it and this context will be checked against the context of an application that is to be the target of a paste operation. Klipper will also have to support relabeling clipboard data. Therefore if I want to cut text from my email client (Kmail) and paste it into Firefox then I would have to relabel it with the appropriate MCS categories. This would permit me to paste text from an email into a web form with a few extra mouse clicks, but would prevent me from accidentally pasting the wrong text. Keeping in mind the fact that there are many more embarassing things that could be accidentally pasted into a blog entry than the contents of a spam this doesn’t seem overly difficult.

PS Before anyone jumps to conclusions. When I receive GPG encrypted email or other material that should be kept confidential I try and avoid cutting it, and if I have to do so I clear the clipboard buffer afterwards. Keeping spam a secret is not really a priority to me so I didn’t take adequate precautions in this case.

combining two domains in SE Linux

To get the maximum value out of my writing when I am asked a question that is of general interest in private mail I will (without in any way identifying the person or giving any specifics of their work) blog my reply. I hope that not only will this benefit the general readers, but also the person who originally asked the question may benefit from reading blog comments.

The question is “I wonder whether I can define a domain which is a union of two existing domain, that is, define a new domain X, which has all the privilege domain Y and Z has got”.

There is no way to say in one line of policy “let foo_t do everything that bar_t and baz_t can do” (for reasons I will explain later). However you can easily define a domain to have the privileges that two other domains have.

If you have bar.te and baz.te then a start is:
grep ^allow bar.te baz.te | sed -e s/bar/foo/ -e s/baz/foo/ >> foo.te
Then you need to just define foo_t in the file foo.te and define an entry-point type and a suitable domain_auto_trans() rule to enter the domain.

There are other macros that allow operations that don’t fit easily into a grep command, but they aren’t difficult to manage.

The only tricky area is if you have the following:
domain_auto_trans(bar_t, shell_exec_t, whatever1_t)
domain_auto_trans(baz_t, shell_exec_t, whatever2_t)

As every domain_auto_trans() needs to have a single target type those two lines conflict so you will need to decide which one you want to merge. This is the reason why you can’t just merge two domains. Also the same applies for file_type_auto_trans() rules and for booleans in some situations.

a newbie question about SE Linux and anti-spam measures

An anti-spam measure that is used by a very small number of people is that of verifying the sender address by connecting to the sending mail server. For example when I send mail from russell@coker.com.au the receiving machine will connect to my mail server and see whether it accepts mail addressed to russell@coker.com.au and will reject my mail if that isn’t the case.

The problem with this is that if I try to send mail to someone who has their mail server listed as a SPAM source then their efforts to verify my email address will fail and then my message to them will bounce with a confusing error message. This means that if one of the two mail servers involved in the communication is listed in a DNSBL or RHSBL service then all communication will be impossible. There will not be an option for one person to say “please phone me on this number if you can’t send me an email”.

This happened recently when someone from Italy asked me a question about SE Linux. So I will answer here (maybe they read my blog). In any case the answer might be of general interest:

Firstly I have to note that I have a B.Sc degree and no post-graduate qualifications, so it is not accurate to address me as Dr. Coker.

The question is: Let’s imagine a user acquire root rights. Especially on Fedora Core, which modify su command to map it to sysadm_r role, couldn’t he/she simply disable SELinux, delete logs, and so on?

If a user obtains ultimate privileges then they can do all things including deleting logs etc.

One thing to note is that there is no need for any process other than kernel threads to have ultimate privs, it would be useful in some situations to make log files append-only for all processes and the SE Linux policy language supports this.

The nearest any release policy comes to implementing such things is the separation between sysadm_r and secadm_r in the MLS policy in recent versions of Fedora.

Also note that it is possible to configure a SE Linux policy that does not permit any process to request that a new policy be loaded, the policy files be changed on disk, or the use of programs such as debugfs. Using SE Linux to enforce a policy that can not be bypassed by anything less than booting from installation media is quite easy to achieve.

One idea that I had was to have GPG implemented in the system BIOS and have GPG checks performed on the kernel before it’s loaded (to verify that the kernel had not been modified). The kernel could be passed a decryption key for the root filesystem by the BIOS, and SE Linux would be enabled as soon as the root filesystem was mounted. Thus nothing less than disassembling the BIOS would allow a hostile person to access the data on the disk. This is all possible with technology that has been common for many years. I almost convincced a BIOS author to implement this in about 2002.