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

'chroot()' Jails or Cardboard Boxes

From Clifton Flynt sometime before Wed, 02 Dec 1998

Hi, You recently stated:

You can set up inetd.conf to call simple chroot call to a jail before launching ftpd -- which will automatically use the /etc/passwd that's relative to the chroot directory. The You can even use shadow passwords in the chroot.

It does take a bit of tweaking -- but it can be done.

Could you point me to a FAQ or HowTo for this?

I'm upgrading a 4.2 based firewall system to 5.1, and already tried the obvious tricks of copying the /lib/security and /etc/pam.d directories to the playground/jail directory.

Thanks,
Clif

I don't know of an FAQ or HOWTO on this. I haven't had time to write one myself.

One trick is to use the 'ldd' command extensively to identify shared libraries that must be copied into the 'chroot()' jail. Another is to use 'strace' to capture system call traces of each program (particularly those that fail to run properly in the jail) and compare the calls to 'open()' between the version run in the jail and the one that works normally within your normal environment.

The brute force method is to simply install a whole distribution unto another filesystem. Mount that as the jail and trim out everything you don't need.

It should be noted that 'chroot()' jails are not "root safe" under normal implementations of Unix and Linux. If an attacker does successfully gain 'root' privileges with the jail it is a simple matter to "break out."

'securelevel' is a set of features in BSD (Free|Net|Open and BSDI/OS) to minimize the persistence of such compromise. These try to prevent root from exercising various privileges while the system is in "server" or "production" or "secure" mode.

There were some patches for 'securelevel' that were under development for Linux. However, Linus rejected them and has accepted an alternative that may offer more flexibility, finer grained control and still allow for relatively easy "securelevel emulation."

These features (what POSIX.1e refers to as "capabilities lists" but which are better described as "VMS like privileges") are built in the 2.1.x kernels and will almost certainly be part of 2.2. In addition to the possibility that these will allow us to "emulate 'securelevel'" these may also prevent many forms of process subversion that lead to 'root' compromise.

Normal 'securelevel' does nothing to prevent the attacker from gaining root. It doesn't very little to limit what the attacker can do with that privilege during the session in which it is obtained. In other words the successful attacker still has control of the system. 'securelevel' primarily prevents persistent changes to the filesystems (no changing immutable flags to mutable and "append-only" files to random access read/write, no remounting read-only filesystems in read/write mode, etc). Some other securelevel features prevent loading of kernel modules and access to /dev/kmem (/proc/kmem for Linux users).

This doesn't address the mechanism by which the attacker gained 'root' and only places relatively minor limitations on what 'root' can do to the state of the system. Those limitations mostly prevent sniffing on other processes, hiding the attacker tracks, and leaving 'rootkits' laying around.

With the "privs" features the Linux kernel add more fine-grained delegation and limitation semantics. One can provide a process (and its descendents) with the ability to open a "privileged" TCP port (below the conventional Unix 1024 watermark) and/or with just read-only access to all files, without allowing that process to write to, change the ownership or permissions/mode or filesystem dependent attributes/flags on them, etc).

Basically these "privileges" split the implications of "SUID root" into separately maskable and delegateable items. Instead of one "god flag" we have a whole pantheon of them, each with its own sphere of influence.

The kernel support for this is just the tip of the iceberg. Consequently we probably won't see effective use of this for several month after Linux ships and it will be much longer until we have "full" support for this security model.

Currently the only way to use these features with 2.1 kernels would be to write wrapper programs that set/mask the privilege sets (there are "allowed, effective, and inheritable" sets; the "inheritable" set is a mask which strips these privs from children). These wrapper/launchers could then start processes with small lists of required privileges and some (small?) assurance that these processes couldn't perform some forms of mischief directly.

To emulate 'securelevel' you'd write wrappers that started 'init' and/or 'inetd' and various daemons like 'sendmail' and your web server with a set of privileges masked off. These processes and their children would be unable to exercise certain sorts of system calls (possibly including the equivalent of 'chroot(..)' to chdir/chroot out of a jail) and file operations. They would not be able to inherit these privileges even from an SUID 'root' program --- such programs would only be able to exercise the subset of privileges that were inherited and allowed. (*)

• (The attack vector would then have to be via subversion of some running process that retained its privileges i.e. via some form of interprocess communication rather than by direct execution. If 'init' was stripped of its "chatter +i" priv then no process on the system could make immutable files mutable. Naturally you'd construct the wrapper or patches to 'init' such that these features would be enabled at specific runlevels or disabled with certain boot-time parameters).

Later it will be possible to store these privilege sets as attributes of executable files. Thus the 'rsh' and 'rlogin' commands would have their "bind to privileged IP port" bit set, and all others would be unset. (Note we're not masking off the other privs, we're merely not granting them). Thus the reason why these two command are "SUID 'root'" is accounted for, without giving these programs a host of other system privileges that are not required for their proper operation.

The filesystem support for these features will presumably be added in the 2.3 kernel series.

It looks like Linux 2.3 will mostly be about filesystems, "large" file support, ACL's, logging/journaling, b-tree directory structuring, and other features of that sort.

It's not clear whether these will be rolled into ext2 or whether they will be incorporated into a new ext3.

If this whole "privs" security model seems complex and difficult to administer and audit, then you're reading me loud and clear.

Determining the precise set of requisite flags for each program and process will be a monumental pain. It is unclear how effective these efforts will eventually be. VMS has had these sorts of features since its inception, and they are similar to features in MLS/CMW (multi-level security for compartmented mode workstations) versions of Unix (usually billed/sold as the B2 Security Package, Option, or Version --- and generally only used by the U.S. military or similar organizations).

Personally I would like to see a "true capabilities" subsystem implemented. This is a completely different security model that is so much unlike Unix, NT, and other identity/ACL based systems that you may have to spend a year or two unlearning what you know about operating systems design before you "get it." (It took me about two --- but I'm unusually stubborn).

I've talked about this security model in this column before. Do a keyword search on EROS (extremely reliable OS) and/or KeyKOS to find some links about it. Ironically I've never used a system that incorporated "capabilities." However, I've grudgingly come to the conclusion that they represent a better security model than the ones we use in all major software today.

The catch is that programs would have to be significantly retooled to work under such a system. There's also been almost no interest in this from the programmers that I've talked to. (That would suggest that I'm just a ranting crackpot --- since I'm not a programmer myself).

In any event, hopefully these "privileges" will make your system somewhat more secure and make a chroot() jail more than just a cardboard box.

If security is not your primary concern -- if all you want is to provide virtual FTP hosting, just look at ncftpd and or ProFTPD.

Copyright © 1999, James T. Dennis
Published in The Linux Gazette Issue 36 January 1999

						a	b	c	1	2	3	4	5	6	7	9	10	11	12
						15	16	18	19	20	21	22	23	24	25	26	27	28
						29	31	32	33	34	35	36	37	38	39	40	41	42	44
45	46	47	48	49	50	51	52	53	54	55	56	57	60	61	62	63	64	65	66
67	69	72	76	77	78	79	80	81	82	84	85	86	87	91	94	95	96	97	98