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."

Comments

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.

Re:misleading...

[nine-times]

Honestly, I might be in the classification of people who don't understand, but I resent the implication of "incompetent". I really hate the idea that you have to be an all-knowledgeable ubergeek, or else stay completely away from computers.

It seems like a simple issue: people have obviously felt the need to jail users for security reasons. They've been lead by someone to believe that chroot is a solution. If chroot isn't the solution, then why not give people a better solution instead of calling them incompetent.

It reminds me of a discussion that I was involved in a while back. I'll tell the story:

I posted to a forum asking what the best method was to jail SFTP users. I wanted something like FTP, but secure, and I didn't want users to be able to browse the whole filesystem. Some security expert chimed in basically calling me a moron, that if I didn't want people to browse the whole filesystem, I should use FTP and jail people. A lot of people in the forum agreed.

I tried to explain that I didn't want to use FTP because authentication wasn't encrypted, but if I must use FTP did anyone know how to get encryption on the login. The same security expert chimed in again to inform me that there wasn't actually a good implementation for SSL on FTP. A lot of people in the forum agreed.

I replied again asking more general advice. I wanted some kind of FTP-type login where authentication was encrypted and users were jailed. Again, it was implied that I was a moron. I was told I didn't understand security at all. I was told: If you trust your users, you shouldn't need to keep them from browsing the filesystem. If I didn't trust my users, then I should only worry about protecting my system from users, and jailed FTP logins were a good solution.

I tried to explain again that I didn't want to trust my users, but I wanted to protect my users' information by providing a secure method for login. The reply again was that I was stupid and incompetent, didn't understand security, and shouldn't be running a server anyway. Many people in the forum agreed.

So all I wanted was to know how to do something, and everyone thought it was a lot of fun to tell me how incompetent I was. If the answer is so obvious, why not explain it? More to the point, if you're such a fricken genius, why not figure out a way to get people the functionality they want in a form they'll understand? I still don't understand why secure authentication is a silly thing to want.

Assuming that everyone running a server is going to be a super-genius who wants to spend all day researching everything-- having that expectation is retarded. I've been working in IT for a while, and I'll tell you right now that there are an awful lot of admins that are way dumber than I am. A solution that only super-geniuses can figure out isn't a practical solution because no one will use it.

So if a lot of people want to jail users into a specific directory for various reasons, why can't we have that functionality? If one particular method (in this case, chroot) doesn't do a good job of jailing users, then can one of the super-geniuses out there come up with a good/real/practical/secure method for accomplishing that?

If you can't, please refrain from name-calling because they want to do something that you can't figure out how to accomplish.

Chroot as a non-security tool

[BurningSpiral]

The purpose of chroot is to change the root directory. Chroot is particularly useful for recovery and diagnostics.

If you system that won't boot due to a boot sector problem Boot from a CD, mount your partitions, chroot to your root partition and run lilo/grub/... to rewrite your boot sector.

If you system that won't boot due to init script problems Boot from a CD, mount your partitions, chroot to your root partition and run run your full init process. If you run into problems, rerun your init scripts rather than rebooting.

Unfortunately, many people think chroot is a security tool so many people don't think it in non-security contexts.

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:Then what is it for?

[soloport]

What's it for?

https://portal.mytesting.org:8080/ (including)
* tinyHTTP (AppWeb, Apache, etc.)
* SQLite (MySQL, Postgres, etc.)
* [chroot-path-0]/www/html/*
* Other ([chroot-path-0]/usr/lib, [chroot-path-0]/bin, etc.)
and repeat...

https://my-test-env.org:8081/

https://my-test-env.org:8082/

https://my-test-env.org:8083/

https://my-test-env.org:8084/ Next, bind /proc to all 5. Then make a script to easily update them from SVN. Done.

Now you have 5 chroot'ed web environments to help your test team (of 5) speed up Alpha testing. May be fraught with bad security? That's not the point.

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.

Re:Not for security use?

[kfstark]

$ cd /tmp
$ ls -l /bin/bash
-rwxr-xr-x 1 root root 700560 2007-04-11 09:32 /bin/bash
$ ln /bin/bash foo
$ ls -l foo
-rwxr-xr-x 2 root root 700560 2007-04-11 09:32 foo

Uhhh, why is a regular user allowed to create a file owned by root? 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.

If root were to rm /bin/bash, the file would still exist and have the proper ownership and be accessed through /tmp/foo

Your way, I could do the following on a file with 600 permission:

cd /tmp
ln /sbin/protected_file mine
chmod 666 mine
cat mine

Nice and easy way to get around a 600 permission.

The behavior is correct, not a bug.

Regards,

--Keith

Re:misleading...Re:Asshole Stereotype

[Jah-Wren Ryel]

'incompetent people implementing security solutions are a real problem.'

Man, things like this make me want to NOT switch to Linux... Even though I had a better experience with Ubuntu that I did Vista. What's your problem with that statement?
It's absolutely true and it is not limited to linux.

Let's take it a few more steps further as an example:

'incompetent people designing bridges are a real problem.'

'incompetent people performing surgery are a real problem.'

'incompetent people running the government are a real problem.'
Do you have a problem with any of those statements?

If you don't even know what chroot() is, then you are not the target of the man's complaint.

Re:misleading...Re:Asshole Stereotype

[bfields]

Man, things like this make me want to NOT switch to Linux... Even though I had a better experience with Ubuntu that I did Vista.

Go ahead. One of the (many) differences between Vista and Linux is that if you want to, you can march up to any of the core Linux kernel architects and tell them they have some fundamental long-standing unix interface totally wrong. The flip side of that is that they also won't stop anyone from flaming you if you do that.

And that's exactly what happened here. This guy wasn't posting a question on a local LUG. He was posting to the Linux kernel mailing list--the place where people actually meet to do kernel development. And he wasn't asking a question, he was arguing with people like Al Viro, a primary architect of the Linux filesystem api's. Which would be great if he was correct. But in fact he was totally wrong. And even that would be OK if he took the time to do his homework and to listen carefully when people explained the issue to him.

But he didn't really, so as a result he got a few flames. Some of the posters to lkml aren't polite in such a situation. I think that's kind of understandable, though actually agree that that's a problem. Are the core Vista kernel developers any better? Who knows? Does the general public doesn't have the option of participating in their development forums?

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

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.''