1

Lintian and Executable Stacks

Debian has a program called Lintian that is used to search for common bugs in Debian packages. When it encounters a package with a shared object that requests an executable stack (as described in my previous post about executable stacks and shared objects [1]) it gives a warning such as the following:
W: liblzo1: shlib-with-executable-stack usr/lib/liblzo.so.1.0.0

Lintian is run automatically on Debian servers and has a web site at http://lintian.debian.org/. You can search the site for all packages which have such executable stacks [2].

Of all the packages listed I have only two installed on my system, liblzo1 and libsmpeg0, both of which I had already discovered and built new versions with the correct stack settings (I’ll publish an APT repository shortly). For the rest I am not sure whether they are really bugs. The ones that concern me are xserver-xorg-video-nsc (we don’t want a stack smashing attack on something as important as an X server) and the C libraries libuclibc0 and dietlibc which may cause many programs to run with an executable stack.

The above URL shows that libffcall1 [4] has this problem (as Eddy discovered [5]). Eddy filed Debian bug report 445895 [6] about this problem (I have just updated the bug report with a patch to make it work on i386).

Linda (an alternative to Lintian) does not currently warn about this. I have filed Debian bug report 445826 about this [3].

6

How SE Linux Prevents Local Root Exploits

In a comment on my previous post about SE Linux and worms/trojans [1] a user enquired about which methods of gaining local root are prevented by SE Linux.

A local exploit is one that can not be run remotely. An attack via TCP or UDP is generally considered a remote exploit – even though in some cases you might configure a daemon to only bind to localhost (in which case the TCP or UDP attack would only work locally). When compromising a machine it’s not uncommon for a local exploit to be used after a remote exploit or social engineering has been used to gain non-root privileges.

The two most common types of local root exploit seem to be those which attack the kernel and those which attack a SETUID process. For a non-SE Linux system it usually doesn’t matter much how the local exploit is run. But a SE Linux system in a default configuration will be running the Targeted policy that has almost no restrictions on a user shell session. So an attacker who wants to escalate their privileges from local user to local root on a typical SE Linux system has a significant benefit in starting from a user account instead of starting from a web server or other system process.

In the SE Linux model access is granted to a domain, and the domain which is used for a process is determined by the policy based on the domain of the parent process and the labelling of the executable. Some domains are not permitted to transition to any other domains, such as the domain dhcpd_t (used for a DHCP server). Other domains are only permitted to transition to a small set of domains, for example the domain httpd_t (used for a web server) can only transition to a small number of domains none of which has any significant privileges.

On a machine running without SE Linux a compromise of a DHCP server is game-over as the server runs as root. A compromise of a daemon such as Apache on a machine without SE Linux gives unrestricted access to run applications on the systems – if a SETUID-root program has a security flaw then you lose. The same bug in a SETUID program on a machine running SE Linux is not fatal because SE Linux will prevent the program from doing anything that it’s parent could not do – even if an attacker made Apache run a buggy SETUID program the broken program in question could do nothing other than what Apache is normally permitted to do.

A security flaw in a SETUID-root program on a SE Linux system can still be exploited by a local user (someone who has logged in) when running the Targeted policy. When running the Strict or MLS policies many such vulnerabilities will not be exploitable by local users (for example exploiting PING would only permit network access).

As a rule of thumb you should consider that a kernel security flaw will make it possible to bypass all other security features. However there are some situations where SE Linux can prevent local exploits. One example is a bug discovered in July 2006 which allowed the creation of SETUID files under /proc [2], the targeted policy of SE Linux prevented this from working. Another example is CVE-2003-0127 [3] (a kernel security flaw that was exploited by triggering a module load and then exploiting a race condition in the kernel module load process), the commonly used exploit for this did not work on a SE Linux system because the user process was not permitted the socket access used to trigger the module load (it is believed that an attacker could have written a version of the exploit to work on a SE Linux system – but AFAIK no-one ever did so).

8

Can SE Linux Stop a Linux Storm

Bruce Schneier has just written about the Storm Worm [1] which has apparently been quietly 0wning some Windows machines for most of this year (see the Wikipedia page for more information [2]).

I have just been asked whether SE Linux would stop such a worm from the Linux environment. SE Linux does prevent many possible methods of getting local root. If a user who does not have the root password (or is not going to enter it from a user session) has their account taken over by a hostile party then the attacker is not going to get local root (unless there is a kernel vulnerability). Without local root access the activities of the attacker can be seen by a user logged in on another account – processes will be seen by all user sessions if using the SE Linux targeted policy and files and processes can be seen by the sys-admin.

If while a user account is 0wned the user runs “su –” (or an equivalent command) then in theory at least the attacker can sniff this and gain local root access (whether enough users do this to make attackers feel that it’s worth their effort to write the code in question is something I couldn’t even guess about). If the user is clueless then the attacker could immediately display a dialog with some message that sound urgent and demand the root password – some users would give it. If the user is even moderately smart the attacker could fake the GUI dialogues for installing updated packages (which have been in Red Hat distributions for ages and have appeared in Debian more recently) and tell the user that they need to enter the root password to install an important security update (oh the irony).

In conclusion I think that if a user is ill-educated enough to want to run a program that was sent to them in email by a random person then I expect that the program would have a good chance of coercing them into giving it local root access if the user in question had the capability of doing so.

Even if a Linux trojan did not have local root access then it could still do a lot of damage. Any server operations that don’t require ports <1024 (which means most things other than running a web, DNS, or mail server) can still be performed and client access will always work (including sending email). The trojan would have access to all of the user’s data (which for a corporate desktop machine usually means a huge network share of secret documents).

If a trojan only attempts to perform actions that SE Linux permits (running programs from the user’s home directory, accessing servers for DNS, HTTP, IRC, SMTP, and other protocols – a reasonable set of options for a trojan) then the default configuration of SE Linux (targeted policy) won’t stop it or even log anything. This is not a problem with SE Linux, just a direct result of the fact that in every situation a trojan can perform all operations that the user can perform – and if the trojan only wants to receive commands via web and IRC servers and send spam via the user’s regular mail server then it will be a small sub-set of the permitted operations for the user!

If however the trojan tries more aggressive methods then SE Linux will log some AVC messages about access being denied. If the sys-admin has good procedures for analysing log files they will notice such things, understand what they mean, and be able to contain the damage. Also there have been at least two cases where SE Linux prevented local root exploits.

Finally, in answer to the original question: SE Linux will stop some of the more aggressive methods that trojans might use. But there are still plenty of things that a trojan could do to cause harm which won’t be stopped or audited by SE Linux policy. When Linux gets more market share among users with a small amount of skill and no competent person to do sys-admin work for them we will see some Linux trojans and more Linux worms. It will be interesting to see what methods the trojan authors decide to use.

4

Executable Stack and Shared Objects

When running SE Linux you will notice that most applications are not permitted to run with an executable stack. One example of this is libsmpeg0 which is used by the game Freeciv [1]. When you attempt to run the Freeciv client program on a Debian/Etch system with a default SE Linux configuration (as described in my post on how to install SE Linux on Debian in 5 minutes [2]) then you will find that it doesn’t work.

When this happens the following will be logged to the kernel log and is available through dmesg and usually in /var/log/kern.log (Debian/Etch doesn’t have auditd included, the same problem on a Fedora, RHEL, or CentOS system in a typical configuration would be logged to /var/log/audit/audit.log):
audit(1191741164.671:974): avc: denied { execstack } for pid=30823 comm=”civclient” scontext=rjc:system_r:unconfined_t:s0 tcontext=rjc:system_r:unconfined_t:s0 tclass=process

The relevant parts are in bold. The problem with this message in the message log is that you don’t know which shared object caused the problem. As civclient is normally run from the GUI you are given no other information.

So the thing to do is to run it at the command-line (the avc message tells you that civclient is the name of the failing command) and you get the following result:
$ civclient
civclient: error while loading shared libraries: libsmpeg-0.4.so.0: cannot enable executable stack as shared object requires: Permission denied

This makes it clear which shared object is at fault. The next thing to do is to test the object by using execstack to set it to not need an executable stack. The command execstack -q /usr/lib/libsmpeg-0.4.so.0.1.4 will give an “X” as the first character of the output to indicate that the shared object requests an executable stack. The command execstack -c /usr/lib/libsmpeg-0.4.so.0.1.4 will change the shared object to not request an executable stack. After making such a change to a shared object the next thing to do is to test the application and see if it works correctly. In every case that I’ve seen the shared object has not needed such access and the application has worked correctly.

As an aside, there is a bug in execstack in that it will break sym-links. Make sure that the second parameter it is given is the shared object not the sym-link to it which was created by ldconfig. See Debian bug 445594 [3] and CentOS bug 2377 [4].

The correct thing to do is to fix the bug in the source (not just modify the resulting binary). On page 8 of Ulrich Drepper’s document about non-SE Linux security [5] there is a description of both the possible solutions to this problem. One is to add a line containing “.section .note.GNU-stack,"",@progbits” to the start of the assembler file in question (which is what I suggested in Debian bug report 445595 [6]). The other is to add the parameters “-Wa,--execstack” to the command-line for the GNU assembler – of course this doesn’t work if you use a different assembler.

In the near future I will establish an apt repository for Debian/Etch i386 packages related to SE Linux. One of the packages will be a libsmpeg0 package compiled to not need an executable stack. But it would be good if bug fixes such as this one could be included in future updates to Etch.

Context of /dev/xvc0

I have just converted a Fedora Core 5 server to a CentOS 5 Xen Dom0 with Fedora Core 5 as a DomU.

The process took a little longer than expected because I didn’t have console or network access to the DomU initially. It turned out that /etc/modprobe.conf was configured to have the tg3 device for Ethernet while I really needed xennet to get networking going.

The console problem was due to the fact that the device /dev/xvc0 is used for the console in DomU’s and the Fedora Core 5 image was configured for a non-Xen mode of operation. Incidentally it seems a little strange that a default install of CentOS as a DomU will get gettys for /dev/tty[1..6] when none of them seem accessible. After I changed the /etc/inittab file to get the correct name it still didn’t work. It seems that the SE Linux policy in Fedora Core 5 doesn’t have the correct context for the /dev/xvc0 device.

semanage fcontext -a -f -c -s system_u -t tty_device_t /dev/xvc0

So I had to run the above semanage command to change the policy configuration, followed by restorecon /dev/xcv0 to apply the change (although once the change is configured it will apply after the next reboot).

2

Multiple Pointers in X

After having read Brice Goglin’s post about what to expect in X for Lenny [1] the thing that seemed most exciting is the support for Multi-Pointer X [2]. This allows multiple keyboards and mouses with a separate keyboard focus for each. So you can have two people typing two different things on the one desktop.

This should be good for training related to GUI programs and will also have some interesting possibilities for large displays. I wonder if the concept of Pair Programming [3] could benefit from having two keyboards and mouses. The idea is that one person isn’t actively coding, but following what the active coder is doing may require reviewing other code that is not visible on screen.

Another interesting feature is XACE [4] the X Access Control Extension. Among other things this is used for Security Enhanced X. Hopefully I’ll be able to find time to work on SE-X in Debian before Lenny is released.

8

Is SE Linux only for Linux?

I have just been asked for advice on whether SE Linux is Linux specific, and therefore whether code related to SE Linux should always be stored with other Linux specific code instead of being in the main branch of certain free software projects.

One example of SE Linux access controls being implemented on a different OS is the work to port SE Linux to Mac OS/X. Here is a paper on the topic presented at the SE Linux Symposium 2007, and the main site is at http://sedarwin.org. One thing I have been doing is trying to get some friends interested in doing similar work for GNU Hurd (there are some similarities between Darwin and HURD so the work done on Mac OS/X “Darwin” will help the HURD effort). I believe that The HURD has the potential to offer significant security benefits due to the micro-kernel design. One significant problem area in computer security is kernel security flaws, if the kernel can be split into a set of independent processes that run with minimal privileges then the scope of such problems is dramatically decreased – and the possibility of upgrading parts of a kernel on a live machine is provided. As people such as Linus point out there is a performance overhead to micro-kernels, but most machines are idle most of the time anyway. I believe that reliability and security are more important than getting the last 10% of system performance for most machines. The success of Xen is evidence that features other than maximum performance are desired.

Another example of SE Linux access controls on a non-Linux platform is the MAC framework in the TrustedBSD project. This implements SE Linux access controls on top of FreeBSD. From reading the documentation it seems that the amount of changes required to the SE Linux code base for implementation on TrustedBSD was significantly smaller than the changes required for Darwin.

Sun is also apparently considering adding type-enforcement to Solaris. It’s yet to be seen whether this happens and if so whether it is compatible with SE Linux.

So it seems that a significant portion of the SE Linux code base is portable, and in particular the user-space code should port well. The interfaces for and methods labelling files etc should port well between platforms. Therefore I recommend not having SE Linux code split into Linux specific trees and instead having a compile option to enable SE Linux support.

5

SE Linux vs chroot

A question that is often asked is whether to use SE Linux or a chroot to restrict a program.

In Unix chroot is a way of running a program with a restricted set of directories available (it used to be merely a sub-tree but with bind mounts it can be any arbitrary set of directory trees). A chroot can be implemented in a daemon (it can call the chroot(2) system call before it drops it’s privileges) or by a shell script (through the chroot(8) utility). The disadvantages of a chroot are that root can escape from it, a chroot process can see the existence of non-chroot processes (ps and similar programs work in the same way in all chroot environments), and inter-process communication is not prevented. One solution to this is to have an enhanced chroot environment (which typically requires a kernel patch) where the chrooted processes can not run ps without restriction and have other limits applied to what they are permitted to do (there are several kernel patches that implement such restrictions). In the early days of SE Linux development I implemented similar functionality in SE Linux policy (here is the paper I presented at Linux Kongress 2002).

Configuring a chroot environment is inconvenient. If it is configured in the traditional manner (copying files to the chroot instead of bind mounting the directories) then old versions may exist in the chroot after new versions with security fixes have been installed in the main environment.

SE Linux provides better security than a typical chroot environment by controlling all interaction between processes. It provides more flexibility than an enhanced chroot environment by being configured entirely by policy and not requiring a kernel recompile to change the way it works.

I believe that the correct thing to do is to cease using chroot entirely and use SE Linux instead.

2

When to Use SE Linux

Recently someone asked on IRC whether they should use SE Linux on a web server machine (that is being used for no other purpose) and then went on to add “since the webserver is installed as root anyway“.

If a machine is used to run a single non-root application then the potential benefits of using SE Linux are significantly reduced, the issue will be whether the application could exploit a setuid program to gain root access if SE Linux was not there to prevent it.

The interesting point in this case is that the user notes that the webserver runs as root. It was not made clear whether the entire service ran as root or whether the parent ran as root while child processes ran as a different UID (a typical Apache configuration). In the case where the child processes run as non-root it is still potentially possible for a bug in Apache to be used to exploit the parent process and assume it’s privileges. So it’s reasonable to consider that SE Linux will protect the integrity of the base OS from a web server running as root – even for the most basic configuration (without cgi-bin scripts). If a root owned process that is confined by SE Linux is compromised then as long as there is no kernel vulnerability the base OS should keep it’s integrity and the sys-admin should be able to login and discover what happened.

If the web server is more complex and runs cgi-bin scripts then there is a further benefit for system integrity in that a cgi-bin script could be compromised but the main Apache process (which runs in a different domain) would run without interruption.

When a daemon that runs as non-root is cracked on a non-SE system it will have the ability to execute setuid programs – some of which may have exploitable bugs. Also on a non-SE system every daemon has unrestricted network access in a typical configuration (there is a Net Filter module to control access by UID and GID, but it is very rarely used and won’t work in the case of multiple programs running with the same UID/GID). With SE Linux a non-root daemon will usually have no access to run setuid programs (and if it can run them it will be without a domain transition so they gain no extra privileges). Also SE Linux permits controls over which network ports an application may talk to. So the ability of a compromised server process to attack other programs is significantly reduced on a SE Linux system.

In summary the more complex your installation is and the more privileges that are required by various server processes the more potential there is to increase the security of your system by using SE Linux. But even on a simple server running only a single daemon as non-root there is potential for SE Linux to provide real benefits to system security.

2

SE Linux shirts for sale!

Faye and I have created Cafepress stores selling shirts and other things with SE Linux logos, here are the two designs:

Play Machine

t-shirt design with SE Linux play machine root password

SE Linux MLS

t-shirt design with SE Linux MLS logo

There are shirts, coffee mugs, mouse-mats, and other things. The designs feature a graphical representation of MLS security and a variety of text about SE Linux. There are also some baby shirts etc.

If you have any ideas for other SE Linux shirts then please let me know by private mail. I’ll give a free shirt to anyone who has an idea that I implement.