Executable Stack and Shared Objects

October 7, 2007 | etbe

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.

Reducing Automated Attacks

October 6, 2007 | etbe

I read the logs from my servers. The amount of time I spend reading log summaries is determined by how important the server is. On the machines that are most important to me I carefully read log summaries and periodically scan the logs for anything that looks unusual.

The amount of time taken is obviously determined by the amount of data in the logs, so it is a benefit to me (in terms of spending less time) to have smaller logs. It’s also a benefit for me (and the other people who depend on those servers) that I spend my time on things that might be important instead of mindless failed attacks.

One thing that I do to reduce the size of my logs is to run sshd on a non-standard port. This requires using a Port directive in the file /etc/ssh/sshd_config and on the client machines I edit /etc/ssh/ssh_config to include a section such as the following to avoid the need to use the “-p” option for ssh (or the “-P” option for scp):
Host some_server
ForwardX11 no
Protocol 2
HostKeyAlgorithms ssh-rsa
Port 1234

Incidentally I disable X11 forwarding explicitly because it’s a dangerous option which usually isn’t needed, and I specify the ssh-rsa algorithm not because it’s any better than the other option of ssh-dsa but because the possibility of having a secondary option that is normally used adds the possibility that a MITM [1] attack can be performed by an attacker who forces the client to use the non-default protocol (thus giving an unknown host key message instead of a message about an invalid key).

Note that these settings can go in /etc/ssh/ssh_config to apply to all users or in ~/.ssh/config to apply to only one user (IE if you aren’t root on the machine in question).

The practice of avoiding attacks by using non-standard ports is not Security by Obscurity in that the security of my systems does not rely on attackers not knowing the port. Attackers can easily scan all ports and discover which one I use. The fact is that any attacker who does so is a more serious threat than all the attackers who scan port 22 and bother someone else when they discover that nothing is listening, such an attacker deserves to have some of my time used to read the log files related to their attempt.

[1] http://en.wikipedia.org/wiki/Mitm

Context of /dev/xvc0

September 23, 2007 | etbe

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).

Multiple Pointers in X

September 13, 2007 | etbe

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.

ISP Password Change by Untrusted People

September 8, 2007 | etbe

After dealing with Optus phone support [1] in regard to a routine request for a password change I have been thinking about better ways of managing password changes for a large ISP. The first criteria is that the user must have a password that is difficult to brute-force attack at all times. Changing a password to a supposedly temporary value that can be easily guessed (such as “changeme“) is never acceptable. The next criteria is that the help-desk operator should be trusted as little as possible and it would be ideal if they never knew the password.

One possibility that occurred to me is that each bill could have a six-digit pseudo-random number printed on it. This number could be used as an alternate password. When a customer calls up because they lost their password they almost always have their last bill (this is why they print the number for phone support on each bill). The help-desk operator could then push a button on a web based form that makes this pseudo-random number be their new password, thus the help-desk operator would not know the new password and the user would also have it printed out clearly which avoids the confusion from having a password read out in a foreign accent.

Another possibility is to have the password change infrastructure integrated with the CTI [2] system, then the help-desk operator could push a button and have the computer dictate the password without the help-desk operator being able to listen in.

There will always be corner cases where a help-desk operator has to change the password, but if these are rare because the automated system handles most cases then the potential for damage would be limited. Of course it would also be a really good idea to do some statistical tracking of the number of password change requests performed by each operator and investigate those who do significantly more than average. In the past AOL has experienced a variety of security problems related to trojans [3] which probably would have been discovered by such analysis.

Another possible option is that customers with mobile phones could have their new password sent to them by SMS. It’s quick, easy, cheap when done in bulk, and is much harder to intercept than most methods that might be used for transferring passwords.

References:

Is SE Linux only for Linux?

August 31, 2007 | etbe

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.

Never IRC as Root

August 27, 2007 | etbe

Ben Fowler blogs about the issues related to running IRC as root. Google searches for (irc client exploit) and (irc client “buffer overflow”) give a number of interesting web pages. Many of the exploits require the user to perform an action that’s slightly unusual, but why take a chance?

The advice to not run as root while generally sensible (run everything with minimum privileges as much as possible) is IMHO not very useful in recent times (and probably was never very useful). Generally when a user is worried about system compromise they are not worried about attackers having direct hardware access, the ability to corrupt system files, etc. They are worried that the attacker might read their email and access other personal files.

Therefore the instruction should be “don’t run IRC as root or as any account that has access to data which is important to you“. It’s not difficult to start an X-term that runs “exec su – ircuser irc” or “ssh -t ircuser@localhost irc“. Note that the -t option is required for ssh to make it allocate a pty even when receiving a command to run. Note also that in the case of su you need the exec option so that if the irc client is compromised and tries to perform a ioctl(0, TIOCSTI… based attack then it won’t succeed.

In any of these methods make sure that X access is not granted. Until we get Security Enhanced X working in a viable manner any process that can display an X window on your screen can own you totally. There are of course relatively safe ways of doing X, I have previously documented how to configure the Xephyr X server (replacement for Xnest) to allow a process with a different security context to safely display a graphical window on your desktop.

Generally I recommend not using a graphical X client on an untrusted network (IE anything other than an Intranet IRC server). I prefer to do my IRC in an account that’s not even on a machine that I care about and have it run screen so I can disconnect and re-connect from anywhere in the world.

When I first got SE Linux in Debian to be useful (when I could boot and run all programs without problem) I logged on to some IRC channels related to Debian with the security context of root:user_r:user_t. I admit that my actions in this regard could possibly be described as trolling, but I wanted to demonstrate what SE Linux can do. Unfortunately of the many people who told me off for logging in to IRC as root, none of them wanted to hear an explanation of why user_r is safe in this regard. I expect that most of them were running their IRC client in the same Unix account that was used for their email etc (and probably most of them had GPG keys accessible from such an account).

Sigh, it’s so easy to run IRC as a different user – in fact it’s probably the easiest of all network client programs to run in such a manner. There’s no reason not to.

SE Linux vs chroot

August 22, 2007 | etbe

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.

When to Use SE Linux

August 21, 2007 | etbe

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.

SE Linux shirts for sale!

May 23, 2007 | etbe

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

Play Machine

SE Linux MLS

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.

etbe – Russell Coker

Linux, politics, and other interesting things

Category Archives: Security