prevent breaking a chroot() jail?

I'm trying to develop a way to ensure that one can't break out of a chroot() jail, even as root. I'm willing to change the way the syscalls work (most likely only for a subset of processes, i.e. processes that are run in the jail end up getting a marker which is passed down to all their children that causes the syscalls to behave differently).

What should I be aware of? I figure devices (no need to run mknod in this jail) and chroot (as per man page), is there any other way of breaking the chroot jail (at a syscall level or otherwise)?

or is this 100% impossible?

thanks,

shaya

In article <1025877004.11004.59.camel@zaphod>,

int main()

{
	chdir("/");
	mkdir("foo");
	chroot("foo");
	chdir("../../../../../../..");
	chroot(".");
	execl("/bin/sh", "sh", NULL);
}

Run as root and you're out of the chroot jail. This is because chroot() doesn't chdir() to the new root, so after a chroot() in the chroot jail you're suddenly out of it.

Mike.

yes, that's what the man page says. Is that the only hole? i.e. if one changed the semantics of chroot() to also do a chdir() to the new root, would that be fixed? (not arguing on changing this for everything, just for something specific)

thanks,

shaya

Shaya Potter <[email protected]>:

Usually, I see the above sequence more like:

	...
	chdir("/");
	mkdir("foo");
	chdir("/foo");
	chroot("/foo");
	...

Though this doesn't necessarily change the situation.

sure, but it depends on what you are trying to prevent... all of these assume root, and are only possiblilities, not necessarily realities.

signal is one way to bring the system down (as is reboot).

swapon is a way to get to other processes memory (create a swap file, then start swapping to it). This one is difficult to implement effectively.

ptrace may allow access to other processes (not sure - see PTRACE_ATTACH)

Modify the shared libraries (in memory) and you modify all processes that are using it (yes it is read only, but root may be able to change the memory tables). I havent tried this one, and it may not be possible

Use open/read/write/close to get the inode of the real parent directory, then the program creates a new file entry (bypassing mkdir... use read/write) to create a subdirectory link to then cd into. Yes it is an invalid entry.

mmap may allow access to devices or the IO memory mapped area.

use iopl/ioperm to gain access to the I/O ports for devices.

mount may allow a loopback nfs mount (not tested either). This would only grant access to NFS filesystems exported globally, and would fail for those with explicit exports (host specified in the exports). It may also allow the mounting of /proc /devfs (or /devices) which would give access to everything.

There is no good way to trap root. You really need to move to something more secure.. such as a non priviledged root user (capability based, or LSM/SELinux based) and simply remove the privileges from the process before/as it is handed over to the chroot "jail".
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: [email protected]

Any opinions expressed are solely my own.

There are lots of other ways for root to escape from a chroot jail. For example: Take control of another process using ptrace, mknod a new device, use the loopback filesystem to create new devices, mount /proc and modify /dev/kmem, bind to privileged ports and escape over the network, kill servers and re-bind to their addresses, mount a new filesystem, bang on IPC or shared memory, load a loadable kernel module, directly access hardware with iopl(), and so on.

Moreover, note that chrooted root processes can do lots of other harm:
kill all the rest of the processes on the box, set the time of day, set the local hostname, reboot your machine, use sysctl to turn on some dangerous option (e.g., IP forwarding), renice other processes, and the like. This is probably not so good, either.

Chroot is a lot better than nothing, but it doesn't provide a secure jail, especially not for root. However, the following tools are intended to provide a secure jail, and may be of interest to you: SubDomain (http://www.immunix.org/subdomain.html), Janus
(http://www.cs.berkeley.edu/~daw/janus/), and BSD's jail() system call come to mind. Also, may I point you to the Linux Security Modules project
(http://lsm.immunix.org/)? I think you may find it of interest.

I havn't seen vserver mentioned in this thread.

http://www.solucorp.qc.ca/miscprj/s_context.hc

It disables a lot of capabilities (configurable) and other stuff. Worth taking a look at.

/Martin

Never argue with an idiot. They drag you down to their level, then beat
you with experience.

Hi,

Well, since we're talking about root:

- If you had saved the old root before chroot()ing, use that one.
- If you have your whole disk exported via NFS, the prisoner process could use nfs to read files outside the jail
- If you have access to a /dev directory, use /dev/sd?? to do the disc access
- If not, use mknod("dideldei", 600, {68,1}); open("dideldei", O_SYNC); and do as you like.

However, if you aren't running anything you find as root, it's relatively secure.

Regards, Thunder

(Use http://www.ebb.org/ungeek if you can't decode)
------BEGIN GEEK CODE BLOCK------
Version: 3.12
GCS/E/G/S/AT d- s++:-- a? C++$ ULAVHI++++$ P++$ L++++(+++++)$ E W-$
N--- o?  K? w-- O- M V$ PS+ PE- Y- PGP+ t+ 5+ X+ R- !tv b++ DI? !D G
e++++ h* r--- y- 
------END GEEK CODE BLOCK------

Take a look at the GR Security patch. It has a whole bunch of chroot restrictions, and might just do exactly what you want.
http://www.grsecurity.net

Vance

------------------------------------------------------------
 Vance Lankhaar                        [email protected]
 PCSS Yearbook                      [email protected]
 PCSS Computers                    [email protected]
 http://www.crestonbc.com/pcss/   http://www.pcsscreston.ca
------------------------------------------------------------

Followup to:  <1025877004.11004.59.camel@zaphod>
By author:    Shaya Potter <[email protected]>
In newsgroup: linux.dev.kernel

This sounds like a job for [dum de dum dum] capabilities... remember, on Linux root hasn't been almighty for a very long time, it's just a matter of which capabilities you retain. Of course, if you really want to be safe, you might end up with a rather castrated root inside the chroot shell.

If you really want to jail something, use UML.

-hpa

<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt	<[email protected]>

ISTR UML had some security problems (guest processes being able to disrupt host processes or just guest processes being able to disrupt other guest processes). Have those been resolved yet?

Do people use it in production? Last I heard someone had evaluated it, it had ended up consuming way too much CPU per "jail" for whatever reason. Perhaps things are better already...

-- v --

[email protected]

Can you be more specific? That's not ringing any bells with me.

As far as I know, there's nothing that needs to be resolved.

Jeff

Sorry, I should've searched the archives before asking. It was just a thing I had read somewhere, quite a while ago. Can't find the exact reference now, but google does give a couple of hits:

http://online.securityfocus.com/bid/3973/discussion/

I just hadn't heard these having been addressed, but that's most likely just me not following closely enough.

Glad to hear. I'll try it next time I'll need to jail something.

-- v --

[email protected]

Yes

It needs some work, and probably ultimately a couple of assists to do sigaltmm and VM style pagex

Its hairy. You need to avoid devices, root, fd passing from untrusted agents outside the chroot world and shared uid (ptrace) attacks. If you are outside the USA you can do this with NSA SE Linux although in the US you may hit the type enforcement patents.

Alan

Hi!

subterfugue.sf.net, or UML. Its hard to do with chroot(). Think kill(-9, -1).
Pavel

Worst form of spam? Adding advertisment signatures ala sourceforge.net.
What goes next? Inserting advertisment *into* email?