"Linux Gazette...making Linux just a little more fun!"

The Answer Guy

By James T. Dennis, tag@lists.linuxgazette.net
Starshine Technical Services, https://www.starshine.org/

Breakin' Out of the chroot() Jail

Or: adding "disabilities" to Linux

From Ron Arts on 25 Jun 1998

Hello,

I saw a post by your hand from 26 Apr 98 in comp.os.linux.development.system where you said a lot of noteworthy things on linux security. Also I have been talking to Jos Vos from Xopen Systems (who wrote the ipfwadm package).

Both you and he noted the possibility to break out of a chroot jail (once you become root there). It seems that devices are the weak factor.

It seems that letting anyone "become root there" is the weak factor! If we can reduce the need to "become root" --- by providing mechanisms other than "SUID" and "SGID" programs for accessing "privileged" operations than we have made some progress.

One approach would be the POSIX.1e "capabilities" (which are more like VMS style "privileges" than true "capabilities"). There is a bit of preliminary work being done on this in the 2.1.x kernels --- but nothing is likely be usable in 2.2 (so you're looking at Linux 2.4 before there is "stable" support for any of that).

Another approach is to limit the damage that 'root' can do using something like the BSD securelevel features. Last I heard on the Linux kernel mailing list they had dropped plans to put in simple 'securelevel' support in favor of a "more flexible" approach --- which would mesh better with the eventual POSIX.1e ("Orange Book") work.

• (The implementations of 'securelevel' in all of the popular BSD variants, free and commercial have been vulnerable to a few attacks via the /proc filesystem and more recently via ptrace() --- so having Linux adopt one of those designs might not be a sound idea. We'll see).

I'm a little shy on the implementation details and design but I think they said it would essentially be a bit field of limitations that would be set on a per process basis. There would be bits to prevent various syscalls like mknod(), chroot(), mount(), etc. In the POSIX.1e model this would later become the "maximum privileges mask" --- and the individual privileges would be set by meta data on the executable files (think of that as a list of about 80 "P" bits rather than just the SUID and SGID bits we have now).

The argument for this is that we could set any set of this bits we want on the 'init' process (PID 1) to accomplish the same limitations as we get with BSD's 'securelevel'.

That's a pretty compelling argument so far as I'm concerned. My main hesitation beyond that has to do with code complexity. The BSD crowd has been trying to get their 'securelevel' implementations right for years --- and the ptrace() bug was just found a couple of weeks ago.

It's not a simple problem. NT's "object" model (and I use the term "object" very loosely) provides ACL's on files, registry keys, and all sorts of other OS elements. There is work underway to add ACL support to Linux --- over some filesystems at least. However, I'm convinced that ACL's are a fundamentally flawed security model --- and that opinion is based on some pretty good academic work.

Unfortunately the true capabilities security model entails a completely different programming paradigm --- it doesn't translate to Unix conventions at all. In my research (purely "armchair" or "book larnin'") I spent most of my energy trying to unlearn the Unix, Netware, and NT approaches.

You can read more about the capabilities security model at Jonathan Shapiro's "EROS" (extremely reliable OS) web site:

https://www.cis.upenn.edu/~eros/

(EROS is an ongoing research project which will hopefully eventually be available as a production operating system).

I have been thinking about disabling the mount() or better the mknod() systemcall when executed from chroot'ed programs (patching the kernel).

I think the "capabilities" (or Linux "securelevel" or "privmask") patches will allow you to disable access to these sorts of syscalls. I also suspect that these "disabilities" (a more apt description really) will be inherited by all forked processes. They will certainly need to be immutable (by the process) and will have to imply certain disabilities with regards to kmem and /proc access by the 'root' processes that are running within these process groups.

You can look at the existing patches (in the recent 2.1.1xx kernels) and possibly build on that.

Do you think that would be worth the effort? We currently run ftpd, telnetd, sshd and some more things chroot'ed in a very minimal linux environment. Based on the false assumption that even when you make it to becoming root you cannot break out of that.

The assumption that the chroot() jail is inescapable by rogue root processes is very bad. You've discovered that.

The main advantage for chroot() have to do with limiting the number of SUID/SGID programs that are accessible in the effort to exploit various vulnerabilities that are used to get root or other unauthorized access. The other advantage is that you can limit the amount of snooping that a class of users (anonymous and guestgroup ftp, for example) can perpetrate on other users on the system.

In other words you can limit the exposure of your "general" users from some classes of other users. For a long time the most important element of this was to prevent FTP users from grabbing your passwd file and running 'crack' on it. With the advent of shadow password systems that has been much less of a concern.

These days the most common approach to securing systems is to create special, sacrificial hosts for each service and class of users. Linux and {Free|Net|Open}-BSD have made this an increasingly economical and attractive option since we can put any old "junker" 386 or better to work in this sort of role (some people are giving away 386 and 486 systems these days). This is easy enough for commercial sites --- but more of a problem for ISP's and educational sites, which traditionally still have shell access to at least some of their machines.

I think very few programs use mknod(), and that probably are the programs you wouldn't allow in a chroot'ed environment anyway. I also think it would be a relatively small patch, I've done some digging and - not being a kernel expert - it seemed pretty easy. The only thing left to find out is how to detect in the kernel that the current env is chroot'ed.

The kernel obviously already tracks the 'root' directory (device:inode) for every process. I think it's a field in the uarea struct (a data structure maintained by the kernel for every process).

Can you offer any thoughts on this, I'd like to know if I am on the wrong track (again) here.

Thanks in advance,
Ron Arts
Netland Internet Services

Look at the existing (2.1.x) sources for references to "securelevel" and "capabilities" --- I'm sure they're in there somewhere. You can also consider contributing to the Linux Security Audit project. See the following URL's for more details:

The Linux Weekly News article on it (search on the keyword "audit"):

https://www.lwn.net/980625/
 

Their currently archives/web site:

https://www.nas.nasa.gov/Pubs/Mail/archive/linux-security-audit/

If your organization needs these features and is willing to donate some web space and some personnel time and expertise to the project --- you'll be doing yourself and all of us alot of good.

Copyright © 1998, James T. Dennis
Published in Linux Gazette Issue 30 July 1998

	SCOkeys	chroot	dosemu-db	NTauth	cdr	3270	comport
	lilostop	emulate	ppadrivers	database	vacation	nullmodem	lockups
	gzipC	newlook	c500	solprint	vc1shell	memleak	tvcard