Kurt Seifried, [email protected]
There are basically two established Linux distributions with a serious bent on security, ImmunixOS and NSA's SELinux. They both have released working, mature code that you can get ahold of and use. There are possibly other projects, but to the best of my knowledge none are shipping code right now.
The NSA's SELinux is extremely powerful as far as configuring security to a very granular level goes. However, for most people and applications, this level of security is overkill (and there are some significant performance hits as well).
ImmunixOS is aimed at making Linux more robust and improving its survivability in the face of new security flaws. ImmunixOS also has a much gentler learning curve than the NSA's SELinux, and addresses issues that NSA SELinux does not.
SubDomain is a kernel module that mediates system calls such as open, and blocks access to other's that are classified as "dangerous" (mknod, etc.). The other part is a small program that administers it, loading and removing configurations. SubDomain allows you to configure which files a process is allowed to access, how it is allowed to access them (read / write / execute), and allows you to manipulate what child processes are allowed to do.
Currently there are a couple of methods to achieve the task that is vastly simplified with SubDomain.
If you run the program "Bind" (a DNS server) as a non-root user, and only give it write access to the directories it needs, it would still be able to write to the /tmp directory, and read the /etc/passwd file, which has to be world readable. The alternative would be to use ACL's and something akin to NT's "no access" permission, which, when applied to every single file that Bind did not require, would allow you to tightly control access. This, however, would be very difficult to maintain and configure and chances are that you would forget something, or later add something and forget to exclude it.
With SubDomain you simply give named access to the files it needs, and that is all it can access.
Load the kernel module (subdomain.o) and then create a SubDomain configuration file, for example the following file is for XNTPD, which must run as root since it adjusts the system clock, and uses UDP for data transfer making it easy to blind spoof the server. The following configuration allows XNTPD to read the configuration files and libraries it requires, all it is allowed to write to is the drift file (used at boot time to reset the clock), "/dev/null", "/dev/log" (for logging) and to "/tmp", for temporary files. Even if someone exploited this program and gained full access they would not be able to spawn off a root shell or run any useful commands for example, all an attacker could do is toast the drift file and potentially fill up any partition the /etc directory is on, flood the log file, or attempt to exploit another program that uses /tmp, however this makes life for the attacker significantly harder than just being able to spawn off a bash shell.
# XNTPD xntp3-5.93-13
/usr/sbin/xntpd
{
/etc/ntp/drift rw
/etc/ntp/keys r
/etc/ntp.conf r
/etc/nsswitch.conf r
/etc/ld.so.cache r
/etc/protocols r
/etc/resolv.conf r
/etc/host.conf r
/etc/hosts r
/etc/localtime r
/lib/ld-2.1.2.so r
/lib/libc-2.1.2.so r
/lib/libdl-2.1.2.so r
/lib/libnss_nis-2.1.2.so r
/lib/libnss_files-2.1.2.so r
/lib/libnss_nisplus-2.1.2.so r
/lib/libnsl-2.1.2.so r
/lib/libnss_dns-2.1.2.so r
/lib/libresolv-2.1.2.so r
/dev/null rw
/dev/log w
/tmp* rw
}
An attacker could potentially write something to /tmp and then exploit another program that suffers a problem exploitable through /tmp, however they would not be able to simply run the program from the access they had gained through Bind. This software significantly complicates life for attackers as they must exploit multiple holes, and if all your network programs are SubDomain'ed properly then a remote attacker will have a very difficult time spawning off a shell and getting real access. Additionally, depending on how much logging you have turned on, you will see a huge number of error messages in syslog as the application attempts to access files it is not allowed to (hint: XNTPD shouldn't try to run /bin/bash). This type of thing is easily automated.
You can also specify what subprocesses are allowed to do. For example, you may have a cgi program that takes in data through a web interface and then spawns off another program which actually sanitizes and uses the data. This way your web cgi does not need any real access, it simply handles some data, which is then passed to a trusted program (that you have hopefully audited), and through SubDomain granted access to /etc/password for example.
Recently on BugTraq there was an advisory for some software, specifically a CGI program built in Perl that reported back to the company that sold it, and had a back door put in intentionally by the author, supposedly allowing him to shut down your cgi if you pirated it, or format your hard drive. Access to this backdoor was granted through a secret string of text given to the cgi program. Needless to say this string was found quite quickly, allowing people to exploit sites using the cgi program. If you had been running this cgi program with a good SubDomain configuration, damage would have been minimized should someone have used it to try to attack your site. They would not have been able to execute any programs of note, nor read or write files like /etc/passwd. Again, processing your log files regularly and looking for SubDomain violations will provide you with early warning, and a good idea of what is wrong (i.e. are they only trying to read files, or run commands as well).
Crispin Cowan is the chief architect of SubDomain, and CTO at WireX Communications.
Kurt: What is the target market for SubDomain?
Crispin: SubDomain is a major plank in the Immunix security-hardened Linux system. So broadly speaking, if you are interested in the security of your Internet servers, SubDomain and Immunix help you "immunize" them. More specifically, SubDomain is especially effective at protecting a host system from exploitable bugs in vulnerable software that may have been installed on a server, making SubDomain particularly attractive for defending Internet servers. This is especially true for Internet web servers, where the major threat is buggy CGI/Perl code. SubDomain confinement of these flakey CGI scripts protects the rest of the web server from attempts to exploit bugs in the CGI code.
Kurt: When will SubDomain be available?
Crispin: We hope to have an Immunix SDK out by June 1. The Immunix SDK would include tools for writing SubDomain profiles.
Kurt: What will the license for SubDomain be? Will private individuals/companies be able to use it on their servers?
Crispin: We're going to roll our own license. While we have not yet thought up a catchy name for it :-) here's a list of what you can do with SubDomain for free:
On the other hand, we will have certain licensing fees for these kinds of things:
Kurt: What do you see as the main benefit of SubDomain?
Crispin: The main benefit of SubDomain is the ability to run potentially vulnerable software on your server in relative safety. You can think of it as a flexible chroot on steroids. Like chroot, a SubDomain'ed program is prevented from accessing unintended parts of your server, e.g. the Web server and its CGIs can't access the mail server's files. Unlike chroot, a SubDomain profile can grant controlled access to other parts of the system that you want to. If you want to chroot two programs, you have to decide whether they are in the same jail where they are at each other's mercy, or separate jails where they cannot communicate at all. With SubDomain, you can put them in separate jails, but still provide them with a controlled interface.
Kurt: What do you see as the main drawback of SubDomain?
Crispin: The biggest drawback is that, unlike StackGuard, SubDomain protection is not totally automatic. Someone who understands the program has to create the profile that describes the files it can access. The tools in the Immunix SDK will help you do that, but you still have to run the program through a sufficient test suite to touch all the files that it will need to touch.
Addressing this problem is part of why we're giving out freebie copies of SubDomain to individuals. Our hope is that some people will find it useful, and will write SubDomain profiles for their server programs. These profiles can be included in an RPM so that they land in /etc/subdomain.conf. This is harmless on non-SubDomain kernels, and safely confines the program on SubDomain kernels.
Between Crispin Cowan's past work on StackGuard and the simple fact I used SubDomain for about a month in testing and now for almost a month in production (on a 2.2.14 kernel, Red Hat system), I am pretty much convinced as to it's effectiveness. The part I really love is it's brute simplicity. You patch and recompile your kernel (something almost all administrators do for other reasons anyway), reboot, download/create some SubDomain profiles, and load them. That's it, no mucking about with your software, system setup or other things. If you want to update software that is SubDomain'ed, simply do so. Most times your SubDomain profile won't even require any changes. It's also great because it can be used to control software that runs as root, something chroot does not accomplish effectively. About the only thing I don't like is that SubDomain is not OpenSource. However, the source code can be licensed, and Crispin does have a pretty solid track record security wise. The subdomain.o kernel module is only a few thousand lines of code, and under 24k compiled, simplicity and ease of auditing is a major bonus (to contrast, SGI's security patches for Linux are about 3MB's of source code and growing, while they do a lot of things, they are a lot more complex and difficult to configure). SubDomain addresses a large number of widespread problems in a very simple and effective fashion, I like that.
This is one of the more widely used components of ImmunixOS, having been around for several years and being freely available. StackGuard is a set of compiler patches. When you compile software using a StackGuard-enabled GCC, it will help prevent some types of stack smashing attacks (a.k.a. buffer overflows). To quote the StackGuard page:
StackGuard detects and defeats stack smashing attacks by protecting the return address on the stack from being altered. StackGuard places a "canary" word next to the return address when a function is called. If the canary word has been altered when the function returns, then a stack smashing attack has been attempted, and the program responds by emitting an intruder alert into syslog, and then halts.
For it to be effective, the attacker must not be able to "spoof" the canary word by embedding the value for the canary word in the attack string. StackGuard offers a range of techniques to prevent canary spoofing:
- Random canaries: the canary word value is chosen at random at the time the program execs. Thus the attacker cannot learn the canary value prior to the program start by searching the executable image. The random value is taken from /dev/urandom if available, and created by hashing the time of day if /dev/urandom is not supported.
- Null canary: the canary word is "null", i.e. 0x00000000. Since most string operations that are exploited by stack smashing attacks terminate on null, the attacker cannot easily spoof a series of nulls into the middle of the string. This mechanism was originally proposed by "der Mouse" in Bugtraq.
- Terminator canary: not all string operations are terminated by null, e.g. gets() terminates on new line or end-of-file (represented as -1). The terminator canary is a combination of Null, CR, LF, and -1 (0xFF) which should terminate most string operations.
While it won't stop all of them, StackGuard does make life significantly more difficult for an attacker. This software is available by default, and the majority of ImmunixOS software is compiled using this, resulting in fewer successful attacks.
FormatGuard is a relatively new entry to ImmunixOS, but like StackGuard most users will not realize its existence, and many administrators will probably not notice either.
FormatGuard addresses a relatively recent (well known for less than a year) problem in a number of common system calls. Basically, if you took user input without properly validating or filtering it (always a bad idea), it was possible for an attacker to insert malicious characters that could be used to elevate privileges in more than a few programs (WU-FTPD for example).
As fixing every call to printf(), syslog() and so on is nearly impossible, the WireX folks decided to fix the system calls themselves (or at least make them appreciably safer). Thus was FormatGuard born, It's basically a wrapper around these unsafe calls, so that you can use software that probably hasn't been properly audited and not worry as much. Like StackGuard, it makes life quite a bit harder for attackers.
Last but not least, we have RaceGuard and CryptoMark. As far as I know, neither has been released yet. However, RaceGuard is planned for the next release of ImmunixOS. Crispin Cowan (CTO at WireX) had this to say:
It's a kernel enhancement that makes mktemp (and hand-rolled variations) safe to use. In the StackGuard tradition, it detects attempts to race the victim suid root program in progress, and (optionally) either refuses the killer open() call, or kills the victim process. I've been running it on my laptop for a month, and there's a few teething problems, but it basically works. It will be in Immunix 7.1.
CryptoMark is a sort of tripwire-style program, except that it operates in real time (remarkably similar to SecureExe in description). If it is released and works as advertised, it will not only prevent Trojans from running, but will help prevent users from running unauthorized programs.
It's a pity that only WireX and the NSA have decided to put real effort into making more secure Linux kernels and distributions. With the vast majority of vendors taking a very reactive security stance, most users are left out in the cold between the time a problem is found and when a vendor ships a fix.
With programs like ImmunixOS, you actually have a chance of surviving the attack. If it's a buffer overflow StackGuard might stop it; or the attacker will not be able to do as much damage if SubDomain is properly set up.
I doubt large vendors will make the effort, because when it comes right down to it, the majority of computer users will complain about security, but spend money on products with more features even if they are less secure.
Reference links:
http://immunix.org/ - ImmunixOS
http://www.wirex.com/ - WireX, makers of ImmunixOS
http://www.nsa.gov/selinux/ - Security-Enhanced Linux
Last updated 4/10/2001
Copyright Kurt Seifried 2001