Policy

Last year I reported that the policy wasn’t very usable, on the 18th of January I uploaded version 2:2.20110726-2 of the policy packages that fixes many bugs. The policy should now be usable by most people for desktop operations and as a server. Part of the delay was that I wanted to include support for systemd, but as my work on systemd proceeded slowly and others didn’t contribute policy I could use I gave up and just released it. Systemd is still a priority for me and I plan to use it on all my systems when Wheezy is released.

Kernel

Some time between Debian kernel 3.0.0-2 and 3.1.0-1 support for an upstream change to the security module configuration was incorporated. Instead of using selinux=1 on the kernel command line to enable SE Linux support the kernel option is security=selinux. This change allows people to boot with security=tomoyo or security=apparmor if they wish. No support for Smack though.

As the kernel silently ignores command line parameters that it doesn’t understand so there is no harm in having both selinux=1 and security=selinux on both older and newer kernels. So version 0.5.0 of selinux-basics now adds both kernel command-line options to GRUB configuration when selinux-activate is run. Also when the package is upgraded it will search for selinux=1 in the GRUB configuration and if it’s there it will add security=selinux. This will give users the functionality that they expect, systems which have SE Linux activated will keep running SE Linux after a kernel upgrade or downgrade! Prior to updating selinux-basics systems running Debian/Unstable won’t work with SE Linux.

As an aside the postinst file for selinux-basics was last changed in 2006 (thanks Erich Schubert). This package is part of the new design of SE Linux in Debian and some bits of it haven’t needed to be changed for 6 years! SE Linux isn’t a new thing, it’s been in production for a long time.

Audit

While the audit daemon isn’t strictly a part of SE Linux (each can be used without the other) it seems that most of the time they are used together (in Debian at least). I have prepared a NMU of the new upstream version of audit and uploaded it to delayed/7. I want to get everything related to SE Linux up to date or at least with comparable versions to Fedora. Also I sent some of the Debian patches for the auditd upstream which should reduce the maintenance effort in future.

Libraries

There have been some NMUs of libraries that are part of SE Linux. Due to a combination of having confidence in the people doing the NMUs and not having much spare time I have let them go through without review. I’m sure that I will notice soon enough if they don’t work, my test systems exercise enough SE Linux functionality that it would be difficult to break things without me noticing.

Play Machine

I am now preparing a new SE Linux “Play Machine” running Debian/Unstable. I wore my Play Machine shirt at LCA so I’ve got to get one going again soon. This is a good exercise of the strict features of SE Linux policy, I’ve found some bugs which need to be fixed. Running Play Machines really helps improve the overall quality of SE Linux.

• [1] http://etbe.coker.com.au/2011/10/31/selinux-status-2011-10/

Related posts:

1. Status of SE Linux in Debian LCA 2009 This morning I gave a talk at the Security mini-conf...
2. SE Linux in Debian I have now got a Debian Xen domU running the...
3. Debian SE Linux Status At the moment I’ve got more time to work on...

On the 12th of September I started investigating this properly and noticed that when someone tried to connect to ssh with password authentication sshd would SEGV after it was denied access to a shared memory region or a semaphore which had a SE Linux type of unconfined_t. I added some SE Linux auditallow rules and discovered that the memory region in question was created by the ssh client. Shortly after that I came to the conclusion that this wasn’t some strange feature of ssh (or one of the many shared objects it uses) but hostile activity. The ssh client appeared to be storing passwords that it used in a shared memory region and sshd was also collecting passwords in the same region and presumably offering them to a ssh client which uses some extension to the ssh protocol.

The sshd process was crashing because it couldn’t handle EPERM on access to shared memory or semaphores. Presumably if the system in question wasn’t running SE Linux then the exploit would have remained undetected for a lot longer.

At this stage we don’t know how the attacker got in. Presumably one of the people with root access ran a ssh client on a compromised system and had their password sniffed. One such client system was mysteriously reinstalled at about that time, the sysadmin of the system in question claimed to have no backups which made it impossible to determine if that system had been compromised. I believe that the sysadmin of the client system knew that their system was compromised, kept that information secret, and allowed other systems to become and remain compromised.

The attacker made no good effort to conceal their presence, they replaced ssh, sshd, and ssh-add and didn’t bother changing the Debian checksums so the debsums program flagged the files as modified. Note that I have kept copies of the files in question and am willing to share them with anyone who wants to analyse them.

Steinar H. Gunderson has named this trojan Ebury [1].

Recovery

By the evening of the 13th of September I had the system mostly working again. Jabber still isn’t working because ejabberd is difficult to get working at the best of times, I am now investigating whether there is a better Jabber server to use, but as I don’t use Jabber often this hasn’t been a priority for me.

Some of the WordPress plugins I use and all of the WordPress themes that are installed were outside the Debian packaging system, as I couldn’t be sure that they hadn’t been altered (because the people who wrote WordPress plugins don’t keep old versions online) I had to upgrade to the newer versions. Of course the newer versions weren’t entirely compatible so I had to use a different theme and I couldn’t get all plugins working. Link Within no longer works, not that it ever worked properly [2], I wanted to try Outbrain again but their web site won’t let me login (and they haven’t responded to my support request). Does anyone know of a good WordPress plugin to provide links to related content? Either related content on my blog or on the Internet in general will be OK.

Some people have asked me about the change in appearance of my blog. It was simply impossible (for someone with my PHP skills) to get my blog looking the same way as it did before the server was cracked. I think that the new look is OK and don’t mind if people think it looks likw a VW advert – VW make great cars, I was very satisfied with the VW Passat I used to drive.

Future Plans

I had bought some Yubikeys (USB devices that generate one-time passwords) [3] to control access to that server, if I had configured the software to use them then this might not have happened. The use of one-time password devices can prevent passive password-sniffing attacks. It would still allow active attacks (such as using ControlPath/ControlMaster options on the ssh client to allow a hostile party to connect later (EG the -M, -S, and “-o ControlPersist” options for the ssh client). It’s a pity that there doesn’t seem to be a way to configure the ssh server to disable ControlMaster.

Conclusion

It would be good to have some changes to sshd to allow more restrictions on what a client can request, as ControlMaster functionality isn’t needed by most users it should be possible to disable it.

SE Linux doesn’t protect against a compromised client system or any other way of stealing passwords. It did do a good job of stopping Ebury from doing all the things it wanted to do and thus making me aware of the problem. So I count this as a win for SE Linux.

Yubikeys are the cheapest and easiest way of managine one-time passwords. I had already bought some for use on the system in question but hadn’t got around to configuring them. I have to make that a priority.

• [1] http://be-geek.com/linux/2011/11/15/steinar-h-gunderson-ebury-a-new-ssh-trojan
• [2] http://etbe.coker.com.au/2010/04/30/link-within/
• [3] http://www.yubico.com/

Related posts:

1. Email Passwords I was doing some routine sysadmin work for a client...
2. Case Sensitivity and Published Passwords When I first started running a SE Linux Play Machine...
3. what’s a good blog server for serious blogging? I’m getting sick of blogger. The main thing is that...

Recently I’ve seen a couple of people advocate the concept of secure boot with the stated idea that “root” should be unable to damage the system, as Microsoft Software is something that doesn’t matter to me I’ll restrict my comments to how this might work on Linux.

Restricting the “root” account is something that is technically possible, for much of the past 9 years I have been running SE Linux “Play Machines” which have UID 0 (root) restricted by SE Linux such that they can’t damage the system [2] – there are other ways of achieving similar goals. But having an account with UID 0 that can’t change anything on the system doesn’t really match what most people think of as “root”, I just do it as a way of demonstrating that SE Linux controls all access such that cracking a daemon which runs as root won’t result in immediately controlling the entire system.

As an aside my Play Machine is not online at the moment, I hope to have it running again soon.

Root Can’t Damage the System

One specific claim was that “root” should be unable to damage the system. While a secure boot system can theoretically result in a boot to single user mode without any compromise that doesn’t apply to fully operational systems. For a file owned by root to be replaced the system security has to be compromised in some way. The same compromise will usually work every time until the bug is fixed and the software is upgraded. So the process of cracking root that might be used to install hostile files can also be used at runtime to exploit running processes via ptrace and do other bad stuff.

Even if the attacker is forced to compromise the system at every boot this isn’t a great win for the case of servers with months of uptime or for the case of workstations that have confidential data that can be rapidly copied over the Internet. There are also many workstations that are live on the Internet for months nowadays.

Also the general claim doesn’t really make sense on it’s own. “root” usually means the account that is used for configuring the system. If a system can be configured then the account which is used to configure it will be able to do unwanted things. It is theoretically possible to run workstations without external root access (EG have them automatically update to the latest security fixes). Such a workstation configuration MIGHT be able to survive a compromise by having a reboot trigger an automatic update. But a workstation that is used in such a manner could be just re-imaged as it would probably be used in an environment where data-less operation makes sense.

An Android phone could be considered as an example of a Linux system for which the “root” user can’t damage the system if you consider “root” to mean “person accessing the GUI configuration system”. But then it wouldn’t be difficult to create a configuration program for a regular Linux system that allows the user to change some parts of the system configuration while making others unavailable. Besides there are many ways in which the Android configuration GUI permits the user to make the system mostly unusable (EG by disabling data access) or extremely expensive to operate (EG by forcing data roaming). So I don’t think that Android is a good example of “root” being prevented from doing damage.

Signing All Files

Another idea that I saw advocated was to have the “secure boot” concept extended to all files. So you have a boot loader that loads a signed kernel which then loads only signed executables and then every interpreter (Perl, Python, etc) will also check for signatures on files that they run. This would be tricky with interpreters that are designed to run from standard input (most notably /bin/sh but also many other interpreters).

Doing this would require changing many programs, I guess you would even have to change mount to check the signature on /etc/fstab etc. This would be an unreasonably large amount of work.

Another possibility would be to change the kernel such that it checks file signatures and has restrictions on system calls such as open() and the exec() family of calls. In concept it would be possible to extend SE Linux or any other access control system to include access checks on which files need to be signed (some types such as etc_t and bin_t would need to be signed but others such as var_t wouldn’t).

Of course this would mean that no sysadmin work could be performed locally as all file changes would have to come from the signing system. I can imagine all sorts of theoretically interesting but practically useless ways of implementing this such as having the signing system disconnected from the Internet with USB flash devices used for one-way file transfer – because you can’t have the signing system available to the same attacks as the host system.

The requirement to sign all files would reduce the use of such a system to a tiny fraction of the user-base. Which would then raise the question of why anyone would spend the effort on that task when there are so many other ways of improving security that involve less work and can be used by more people.

Encrypted Root Filesystem

One real benefit of a secure boot system is for systems using encrypted filesystems. It would be good to know that a hostile party hasn’t replaced the kernel and initrd when you are asked for the password to unlock the root filesystem. This would be good for the case where a laptop is left in a hotel room or other place where a hostile party could access it.

Another way of addressing the same problem is to boot from a USB device so that you can keep a small USB boot device with you when it’s inconvenient to carry a large laptop (which works for me). Of course it’s theoretically possible for the system BIOS to be replaced with something that trojans the boot process (EG runs the kernel in a virtual machine). But I expect that if someone who is capable of doing that gets access to my laptop then I’m going to lose anyway.

Conclusion

The secure boot concept does seem to have some useful potential when the aim is to reboot the system and have it automatically apply security fixes in the early stages of the boot process. This could be used for Netbooks and phones. Of course such a process would have to reset some configuration settings to safe defaults, this means replacing files in /etc and some configuration files in the user’s home directory. So such a reboot and upgrade procedure would either leave the possibility that files in /etc were still compromised or it would remove some configuration work and thus give the user an incentive to avoid applying the patch.

Any system that tries to extend signature checks all the way would either be vulnerable to valid but hostile changes to system configuration (such as authenticating to a server run by a hostile party) or have extreme ease of use issues due to signing everything.

Also a secure boot will only protect a vulnerable system between the time it is rebooted and the time it returns to full operation after the reboot. If the security flaw hasn’t been fixed (which could be due to a 0-day exploit or an exploit for which the patch hasn’t been applied) then the system could be cracked again.

I don’t think that a secure boot process offers real benefits to many users.

• [1] http://ncommander.blogspot.com/2011/11/secure-boot-its-here-and-been-here-for.html
• [2] http://www.coker.com.au/selinux/play.html

Related posts:

1. Question about a “Secure Filesystem” I have just been asked for advice about “secure filesystem”...
2. How SE Linux Prevents Local Root Exploits In a comment on my previous post about SE Linux...
3. Logging in as Root Martin Meredith wrote a blog post about logging in as...

deb http://www.coker.com.au wheezy selinux

The above APT sources.list line has my repository for SE Linux packages that have been uploaded to Unstable and which will eventually go to testing and then the Wheezy release (if they aren’t obsoleted first). I have created that repository for people who want to track SE Linux development without waiting for an Unstable mirror to update.

In that repository I’ve included a new version of policycoreutils that now includes mcstrans and also has support for newer policy such that the latest selinux-policy-default package can be installed. The version that is currently in Testing supports upgrading policy on a running system but doesn’t support installing the policy on a system that previously didn’t run SE Linux.

I have also uploaded SE Linux Policy packages from upstream release 20110726 compared to the previous packages which were from upstream release 20100524. As the numbers imply there is 14 months of upstream policy development which changes many things. Many of the patches from my Squeeze policy packages are not yet incorporated in the policy I have uploaded to Unstable. I won’t guarantee that an Unstable system in Enforcing mode will do anything other than boot up and allow you to login via ssh. It’s definitely not ready for production but it’s also very suitable for development (10 years ago I did a lot of development on SE Linux systems that often denied login access, it wasn’t fun).

Kyle Moffett submitted a patch for libselinux which dramatically changed the build process. As Manoj (who wrote the previous build scripts) was not contactable I accepted Kyle’s patch as provided. Thanks for the patch Kyle, and thanks for all your work over the years Manoj. Anyway the result of these changes should mean that it’s easier to bootstrap Debian on a new architecture and easier to support multi-arch – but I haven’t tested either of these.

Squeeze

The policy packages from Squeeze can’t be compiled on Unstable. The newer policy compilation tool chain is more strict about how some things can be declared and used, thus some policy which was fairly dubious but usable is now invalid. While it wouldn’t be difficult to fix those problems I don’t plan to do so. There is no good reason for compiling Squeeze policy on Unstable now that I’ve uploaded a new upstream release.

deb http://www.coker.com.au squeeze selinux

I am still developing Squeeze policy and releasing it in the above APT repository. I will also get another policy release in a Squeeze update if possible to smooth the transition to Wheezy – the goal is that Squeeze policy will be usable on Wheezy even if it can’t be compiled. Also note that the compilation failures only affect the Debian package, it should still be possible to make modules for local use on a Wheezy system with Squeeze policy.

MLS

On Wednesday I’m giving a lecture at my local LUG about MLS on SE Linux. I hope to have a MLS demonstration system available to LUG members by then. Ideally I will have a MLS system running on a virtual server somewhere that’s accessible as well as a Xen/KVM image on a USB stick that can be copied by anyone at the meeting.

I don’t expect to spend much time on any aspect of SE Linux unrelated to MLS for the rest of the week.

Version Control

I need to change the way that I develop SE Linux packages, particularly the refpolicy source package (source of selinux-policy-default among others). A 20,000 line single patch is difficult to work with! I will have to switch to using quilt, once I get it working well it should save me time on my own development as well as making it easier to send patches upstream. Also I need to setup a public version control system so I can access the source from my workstation, laptop, and netbook. While doing that I might as well make it public so any interested people can help out. Suggestions on what type of VCS to use are welcome.

How You Can Help

Sorting out the mess that is the refpolicy package, sending patches upstream and migrating to a VCS is a fair bit of work. But there are lots of small parts. Sending patches upstream is a job that could be done in small pieces.

Writing new policy is not something to do yet. There’s not much point in doing that while I still haven’t merged all the patches from Squeeze – maybe next week. However I can provide the missing patches to anyone who wants to review them and assist with the merging.

I have a virtual server that has some spare capacity. One thing I would like to do is to have some virtual machines running Unstable with various configurations of server software. Then we could track Unstable on those images and use automated testing to ensure that nothing breaks. If anyone wants root access on a virtual server to install their favorite software then let me know. But such software needs to be maintained and tested!

Related posts:

1. Debian SSH and SE Linux I have just filed Debian bug report #556644 against the...
2. /run and SE Linux Policy Currently Debian/Unstable is going through a transition to using /run...
3. SE Linux status in Debian/Squeeze ffmpeg I’ve updated my SE Linux repository for Squeeze to...

The focus of the paper is on the Chromium web browser and six different ways of constraining the Chromium sandbox are compared. For the SE Linux comparison they claim 200 lines of code changes as of Fedora 15, in Fedora 16 I couldn’t find a Chromium package, so I presume that they mean 200 lines of SE Linux policy (I am not aware of anyone modifying the Chromium source for SE Linux). They note that SE Linux doesn’t support separating different sandboxes, while it would be possible to have each sandbox be assigned a different MCS sensitivity label to separate them that option would be unwieldy enough that they are essentially correct in this regard. For SE Linux systems running the MLS policy the correct thing to do would be to run multiple copies of Chromium at different levels to access different sensitivity levels of data, this would normally be done by polyinstantiating the home directory.

One thing to note however is that there is no requirement that only one security method be implemented. I can’t think of any technical reason why it would be impossible to run SE Linux and Capsicum on the same system. SE Linux could constrain daemons and restrict the access to Capsicum services while Capsicum could be used to give minimum privileges to parts of Chromium. I’m not sure that such a combination would offer anything that the MLS users would desire, but it seems that everyone else (the vast majority of computer users) would be served well by a combination of SE Linux and Capsicum.

It’s disappointing that the paper didn’t mention Posix 1003.1e capabilities, but given the lack of use that Posix capabilities get that’s understandable.

It’s also disappointing when someone develops something new and different nowadays and doesn’t provide a virtual machine image for it. Installing and configuring something that requires application and kernel changes is a lot of work and most people who are idly curious about the technology won’t go to the effort. By today’s standards it’s not that difficult to share a 1GB filesystem image via Bittorrent.

• [1] http://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-login-capsicum.pdf
• [2] http://www.cl.cam.ac.uk/research/security/capsicum/

Related posts:

1. SE Linux vs chroot A question that is often asked is whether to use...
2. Creating a SE Linux Chroot environment Why use a Chroot environment? A large part of the...
3. Context of /dev/xvc0 I have just converted a Fedora Core 5 server to...

The SE Linux file labeling program restorecon reads the file /etc/selinux/$SELINUXTYPE/contexts/files/file_contexts which contains a set of regular expressions to assign labels to files. That file is ordered and the last entry which matches is the one that counts. When the file_contexts file is created the order is based on how many characters at the start of the file specification aren’t regular expression meta-characters. For example the entry “/.*” is at the top of the file (and therefore has the lowest precedence), which makes it the catch-all entry for files that have no other match. So an entry for “/var/run/REGEX” will have a higher precedence than one for “/var/REGEX”, this means however that when I replaced the “/var/run” part with a regular expression then it had a lower precedence and it didn’t work properly.

I should have remembered this as I did a lot of work on setfiles (which became restorecon) in the early days. I have now developed a new way of solving this and this time I’m testing it before blogging about it.

I have written the following PERL program to fix the file contexts, this adds multiple lines and uses a distro_debian conditional on them so that they don’t slip into upstream use – and so that if I lose track of where each patch came from I’ll know that I can delete them in future because it only matters to Debian.

#!/usr/bin/perl
use warnings;
use strict;

open(LIST, "find . -name \"*.fc\"|xargs egrep \"^/(var.*run)|(var/lock)|(dev/shm)\"|cut -f1 -d:|uniq|") or die "Can't get file list\n";
while(<LIST>)
{
  my $filename = $_;
  chomp $filename;
  open(my $infile, "<", $filename) or die "Can't open file $filename";
  open(my $outfile, ">", $filename . ".new") or die "Can't open file ". $filename . ".new";
  while(<$infile>)
  {
    print $outfile $_;
    my $newline;
    if($_ =~ /^\/var\/run/)
    {
      print $outfile "ifdef(`distro_debian', `\n";
      $newline = $_;
      $newline =~ s/^\/var//;
      print $outfile $newline;
      print $outfile "')\n";
    }
    if($_ =~ /^\/var\/lock/)
    {
      print $outfile "ifdef(`distro_debian', `\n";
      $newline = $_;
      $newline =~ s/^\/var/\/var\/run/;
      print $outfile $newline;
      $newline =~ s/^\/var//;
      print $outfile $newline;
      print $outfile "')\n";
    }
    if($_ =~ /^\/dev\/shm/)
    {
      print $outfile "ifdef(`distro_debian', `\n";
      $newline = $_;
      $newline =~ s/^\/dev/\/run/;
      print $outfile $newline;
      print $outfile "/var" . $newline;
      print $outfile "')\n";
    }
  }
  close($infile);
  close($outfile);
  rename $filename . ".new", $filename or die "Can't rename " . $filename . ".new to " . $filename;
}

The next policy thing that I have to work on is systemd. From a quick test it seems that systemd policy changes will be more invasive than is suitable for Squeeze. This means that someone who wants to upgrade from Squeeze to Wheezy+systemd will have to upgrade to Wheeze policy before installing systemd. I think that I will make 0.2.20100524-10 the last version in Unstable based on the 2010 release, I will now start work on packaging the latest upstream policy for Unstable.

PS I’m not much of a PERL programmer, so if anyone has suggestions for how to improve the above PERL code then please let me know. Please note however that I’m not interested in making my code look like line-noise.

• [1] http://etbe.coker.com.au/2011/07/22/run-se-linux-policy/

Related posts:

1. SE Linux on /. The book SE Linux by Example has been reviewed on...
2. /run and SE Linux Policy Currently Debian/Unstable is going through a transition to using /run...
3. Context of /dev/xvc0 I have just converted a Fedora Core 5 server to...