When Not to Use chroot

Hyena writes "Linux guru Alan Cox is quoted as saying 'chroot is not and never has been a security tool' in a KernelTrap article summarizing a lengthy thread on the Linux Kernel mailing list. The discussion began with a patch attempting to 'fix a security hole' in the Unix chroot command, trying to improve the ability of chroot to contain a process. When it was pointed out that people have been using chroot as a security tool for years, another kernel hacker retorted, 'incompetent people implementing security solutions are a real problem.' A quick search on the terms 'chroot+security' quickly reveals that many people have long thought (wrongly) that chroot's purpose was for improving security."

misleading...

[onemorehour]

This summary is truly and terribly misleading--the discussion simply says that a root user can break out of a chroot jail. Is this news? chroot can still be effectively used to contain processes that do not run as root.

FreeBSD Jails

[cstdenis]

FreeBSD has a system called jails that do provide the security people are looking for in chroot. In addition to doing a chroot, they also prevent processes from seeing each other and can restrict network functionality.

Its like a virtual machine, but shares the same kernel (with restrictions) so there isn't the performance of full emulation.

Duh.

[wilymage]

This isn't news.

For those of you who weren't aware how easy it can be to break out of most chroots, here's a good description of a common process:

http://www.bpfh.net/simes/computing/chroot-break.html [bpfh.net]

Re:FreeBSD Jails

[cstdenis]

If its used to lock you the computer owner out of the program, its DRM.

If its used to lock the hackers out of the program (or in the program out of the rest of the system) its security.

The big difference between protected processes and Jails is root on the main system can access anything in a jail where as I doubt you can do that in windows (if you can that its useless as DRM so the argument is moot).

Re:Duh.

[Anonymous Coward]

Not a terribly useful article. To quote:

--
For a user to do this, they would need access to:
  - C compiler or a Perl interpreter
  - Security holes to gain root access
--

So, the security tool isn't useful if there's a different security hole you can use to become root, especially when you can create and execute arbitrary code on the machine. No kidding.

We already know that chroot() can be broken with superuser access; that's what superuser access is for. Security holes that grant root access completely destroy the Unix security model, since it really only comes in two levels, and root is by definition unlimited. If I'm allowed simply to assume a way to gain root access as one premise of my new 'sploit, then there is no possible way to secure Linux at all.

Note that half of the discussion in TFA also falls into this trap. Most of the posts are discussing chroot as a shell command, and pointing out that if you're logged in as root it doesn't contain you. Again, no kidding. chroot is a way for a program to set up a samdbox for some other program; that's it. As a interactive shell command, it's mostly pointless.

Re:Not for security use?

[cperciva]

If chroot didn't require root privileges, the following exploit would be possible:

1. Create ~/etc/master.passwd with an empty root password.
2. Hard link /usr/bin/su to ~/usr/bin/su. (Yes, you can create hard links to files which you don't own.)
3. Copy /bin/sh, /bin/chmod, and the necessary libraries to the corresponding places under ~.
4. chroot ~ /usr/bin/su root /bin/chmod 4555 /bin/sh
5. ~/bin/sh is now an unrestricted root shell.

Re:Or is it?

[TheRaven64]

For daemons that run as root, the user should not be using the chroot command. Instead, the daemon should be doing cwd(), chroot(), setuid(). For other processes, you should (as root) do something like chroot su user command, so you drop privileges as soon as you are inside the chroot and can't escape.

Re:Then what is it for?

[larry bagina]

Actually, Bill Joy invented chroot as a hack to use a custom /usr/include directory in a compiler that didn't support alternate include paths.

Re:For daemons that don't run as root

[TheRaven64]

Yes you can. As I said, you launch them with:

# chroot directory su nobody daemon

This will chroot into directory, and run daemon as the nobody user. As long as the version of su inside your jail doesn't have any security holes, you will be fine. If you don't trust it, I've written a modified version of chroot, which calls setuid() and setgid() to a named user and group before executing the named process. This eliminates the need for a working su inside the chroot, typically removing the need for any setuid programs in the chroot.

Just because you can only run a command as a superuser doesn't mean that all of the child processes of that command have to be run as the superuser. If this were the case, since init runs as root you would not have a multiuser system.

Re:misleading...

[NNKK]

It can be used as a safety mechanism for testing non-malicious code. It can also be used to setup an environment that uses different versions of key libraries or utilities from the host to run code that might not otherwise work. Linux distributions tend to make use of the chroot facility for installation tasks, as well.

Using chroot on a process is like handing a person a map with an X on the destination. You've shown them where they're supposed to go, you haven't really done anything to prevent them from running off in another direction.

Re:Not for security use?

[e9th]

Awesome, the semantics of directory permissions are not even honored anymore.. anyone else smell a kludge here?

Remove the sticky bit from /tmp & try again.

Re:misleading...Re:Asshole Stereotype

[visualight]

I think his comment was directed specifically at people who do not have enough understanding to implement a security solution on linux but think they do. Would the same comment coming from an official MS authority on security make you not want to use Vista?

Anyway, I do understand the perspective behind your reaction, but it doesn't fit in this specific case.

Oversimplified...

[evilviper]

It's terribly oversimplified to say that chroot is useless. What's stupid is to chroot a process running as root. Most programs that have the built-in ability to chroot themselves (eg. Apache) immediately drop root privileges and drop to a non-privileged account.

That said, even done properly chroot really only provides a little protection, and only in the case of horribly configured systems... IMHO, the sole benefit of chrooting a process is that anyone who successfully breaks-in can't execute SUID/SGID applications located elsewhere on the filesystem, which very, very commonly have security holes. Proper use of either sudo, or setting-up groups that are the only ones allowed to exec SUID/SGID applications, eliminates this big security hole.

People like to say that chroot prevents attackers from running anything within the chroot, but it really doesn't... No doubt the exploit code used to break-in directly overwrites locations in memory. A similar method can be used to run any code you wish, no matter what is or isn't available inside the chroot. It certainly won't stop someone from exploiting kernel bugs, generating/reading network traffic, etc.

Of course, these are the same types of people that think their systems are safer for having removed the compilers, and other (non-SUID/SGID) binaries that harmlessly occupy HDD space.

Re:I'll bite

[larry bagina]

linux doesn't have jail. However, user mode linux and the like accomplish the same thing.

I've also seen attempts to fake a jail using LD_PRELOAD funstion stubs to filter system calls. However, since the filtering is not done in the kernel, it's possible for another thread to modify the arguments after they've been verified but before they actual system call takes place (ie, a race condition).

There was a slashdot article about this a couple months ago, but damned if I can find it now.

Re:Not for security use?

[MSG]

Uhhh, why is a regular user allowed to create a file owned by root?

They're not. They are, however, allowed to create a name in a directory (a link) that points to an existing inode. Since the inode has all of the owner and permission data, and the user is not allowed to modify the inode, allowing them to create a link to it is not an inherent risk.

Awesome, the semantics of directory permissions are not even honored anymore.. anyone else smell a kludge here?

Yes, they are. /tmp has the "sticky bit" set in its permissions. That means that users aren't allowed to remove or rename a file (link) unless they are the owner. Arguably, that is an odd semantic; since links don't have owners -- only files do -- it's not possible to allow users to remove or rename links that they created. However, claiming that the semantics of directory permissions aren't honored simply shows that you're ignorant of what the semantics are.

chroot, security and other uses

[jmorris42]

> A process running as a regular user can break out too.

Only if it can get access to a broken SUID program, etc. I always though the point of a chroot in a security context was that the chroot only had the absolute minimum environment the task being isolated had to have, thus there shouldn't be too much in there to worry about getting exploited. Which is very useful.

Of course there are lots of uses for chroot that have nothing to do with security. Like keeping a whole 32bit environment seperate from the main 64bit install, wonderful tools like mock which allow keeping multiple distros on multiple arches installed and usable for building packages, etc.

Re:Not for security use?

[Anonymous Coward]

> Apparently, you don't know what a hard link is.
> You haven't created a file owned by root. You've created an i-node pointing to the data blocks of a file owned by root.

Ohh Keith, clearly you have meager understanding of what an inode is (or a hard link is for that mater). A hard link is NOT an inode but a new name-to-inode pointer contained in the directory's data blocks (remember a directory is just a file). When you create a hard link, you just increase the link count on the already existing inode and add an entry (pointer to the inode) in the link's parent directory's "file."

Now a soft link IS a new inode.

Hope that cleared things up for you. I LOVE asking this question during interviews because most Unix Sysadmins don't really know it.

--AC

Re:Chroot as a non-security tool

[xenocide2]

Chroot is also used in building Debian packages. pbuilder sets up a seperate install to chroot into and ensure that build dependencies are correct by copying a base install, installing the build deps and attempting to build the package, eliminating some of those "works for me" FTBFS problems.

Citation

[BobKagy]

Actually, Bill Joy invented <tt>chroot</tt> as a hack to use a custom /usr/include directory in a compiler that didn't support alternate include paths.

http://blogs.sun.com/chrisg/tags/chroot [sun.com]

Dr. Marshall Kirk Mckusick, private communication: ``According to the SCCS logs, the chroot call was added by Bill Joy on March 18, 1982 approximately 1.5 years before 4.2BSD was released. That was well before we had ftp servers of any sort (ftp did not show up in the source tree until January 1983). My best guess as to its purpose was to allow Bill to chroot into the /4.2BSD build directory and build a system using only the files, include files, etc contained in that tree. That was the only use of chroot that I remember from the early days.''

*cough*

[msimm]

Of course now that I'd done the simple search I find it coincidentally, everywhere [howtoforge.com].

Re:Not for security use?

[kocsonya]

> Apparently, you don't know what a hard link is.
>
> You haven't created a file owned by root. You've created an i-node pointing to the
> data blocks of a file owned by root.

No, you didn't.
You created a directory entry pointing to the i-node of the file which is also pointed
by the 'sh' entry in the /bin directory file. In addition, the reference count in the i-node has been bumped up by 1. One file is one i-node and that inode contains the owner, permission and timestamp info as well as the disc blocks that the file uses. For all practical purposes the file and the i-node are the same thing. A dir entry contains a name for the file and a pointer to the inode. There can be as many dir entries in different directories to the same file as you wish. The i-node also contains a reference count of how many dir entries point to it. When you rm a file, it will remove the dir entry and decrement the refcount in the i-node. When the refcount reaches 0, the file is actually deleted (actually it will only be deleted if it is not open at the time, but that's a separate issue).

You can delete a hard link to a file owned by anyone if you have write permission on the directory that contains a link:

zoltan@gep:~> ln /bin/bash foo
zoltan@gep:~> ls -l foo
-rwxr-xr-x 2 root root 572200 2005-09-10 03:43 foo
zoltan@gep:~> rm foo
rm: remove write-protected regular file `foo'? y
zoltan@gep:~>

On the other hand, if you try it in /tmp:

zoltan@gep:~> cd /tmp
zoltan@gep:/tmp> ln /bin/bash foo
zoltan@gep:/tmp> ls -l foo
-rwxr-xr-x 2 root root 572200 2005-09-10 03:43 foo
zoltan@gep:/tmp> rm foo
rm: remove write-protected regular file `foo'? y
rm: cannot remove `foo': Operation not permitted
zoltan@gep:/tmp>

The reason for that strange behaviour is this:

zoltan@gep:/tmp> ls -ld /tmp /home/zoltan
drwxr-x--- 114 zoltan users 16248 2007-09-28 14:23 /home/zoltan
drwxrwxrwt 32 root root 3176 2007-09-28 14:25 /tmp

The /tmp can be written by anyone. Note the 't' at the end of the permissons of /tmp: that is the sticky bit. Normally, if you have write permission on a directory, you can add, delete and rename files in that directory, no matter who actually owns those files (since you do not want to touch the file, you only change the directory file, which you have right to). If the sticky is set, however, an entry can only be removed (or, for that matter, renamed) by the owner of the file pointed by that entry. This is actually a trick (kludge, if you like) to solve the problem that sometimes you need to be able to create files in a common place (e.g. lock files) but you must not let anyone but the owner delete them and the basic UNIX acces right model is not enough for that. One such place is /tmp, an other prominent example is /var/lock. Since creating a hard link is to insert an entry to the directory file you can do it in such a directory - anyone can add entries, as the directory is word-writable. However, if the sticky is set, you can only remove (or rename) an entry if the i-node pointed by that entry is actually owned by you - which is not the case with /bin/bash. It is not because /bin/bash is owned by root, it is because it is not owned by you. It has nothing to do with the i-nodes or hard links, but the way the sticky bit works, which was a really neat trick to solve a problem, but it has this side effect.

Is it a bug? Well, it's certainly a feature... Is it a security problem? I don't know, I am no security expert, but I haven't heard of an exploit based on links and the sticky bit yet.

Re:Or is it?

[h4rm0ny]

as well as removing all the advice that's currently around to chroot processes, if chroot isn't actually for security.

Well a good place to start would be at http://en.wikipedia.org/wiki/Chroot [wikipedia.org] because one of the first things I did when this article came up was to double-check my understanding of chroot right there. FTFW:

This provides a convenient way to sandbox an untrusted, untested or otherwise dangerous program. It is also a simple kind of jail mechanism.

Re:Or is it?

[Rigrig]

By the time I read your comment someone already fixed the Wikipedia entry:

This is often misunderstood to be a security device, used in an attempt to sandbox an untrusted, untested or otherwise dangerous program, as if chroot was a working jail mechanism.

Re:misleading...

[uglyduckling]

See, the majority of "open source" development is all about scratching an itch. Most developers don't have that same itch that you're having. They don't have "users" - they run their own machines, maybe give accounts to a few friends/colleagues, but they don't have the problem that you have. Therefore, the secure FTP with jailing is probably not on the horizon.

Don't be silly, there are open source developers producing and using open source software in 1001 different scenarios. Many people are using Linux or BSDs in university computer labs, small companies, running web servers with shell access. You're right that no-one has developed this yet but there are thousands of network utilities in the Debian source tree and BSD Ports that demonstrate that developers are producing high-quality software for large-scale networked environments.