Slashdot Mirror
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."
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.
The problem is that - for many root-running processes - running chroot has often been recommended as a security practice. This has often been the recommendation of the daemon authors, in the documentation, as a way to improve security.
I think that this was once (or may currently be) the case with bind and various MTA's. Standard practice for many daemons now is to start as root and fork as another non-privileged user, but not every daemon has this option.
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.
1984 was not supposed to be an instruction manual.
Not for improving security, huh?
OK, genius, then explain why chroot() requires root privileges (or chroot capability) to execute.
It's only in the context of security that such a restriction makes any sense at all.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
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
The secret to creativity is knowing how to hide your sources. -- Albert Einstein
And RAID isn't for safety of your data either, hey?
Locks on your house aren't for security, they're just to keep the door closed if a cat pushes on it, right?
Seatbelts aren't to prevent you from flying through a windshield, they're just there so you don't slide around while taking corners.
Sorry, chroot *is* a security tool; it's very much useful for security. Maybe it wasn't written as one - maybe it was never intended to be one, but it *is* one now, no matter what Alan Cox says.
Software, especially open source software, is a lot like language. Despite the best efforts of nitpicking English teachers everywhere, the meaning of both words and code are whatever the vast majority agrees upon. And regardless of that, you may call me crazy, but the ability to restrict what a user can and can't access; what a process can or can't access, sounds like a security tool to me.
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.
'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.
Heck, I don't even know what chroot is, which must make me dried dog piss on a hot fire hydrant in this guy's eyes.
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.
Do you even lift?
These aren't the 'roids you're looking for.
Sorry folks,
Chroot IS an effective layer when you are also dropping privileges from superuser.
Obviously chrooting a "root" process does no good.
But hey, this is slashdot not reality. Go ahead and mod me down.
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.
I am TheRaven on Soylent News
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
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.
Do all OS developers become assholes? I've done a lot with VxWorks and I hope I don't become as twisted as these folk. I better just stay away from authoring my own kernel.
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.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
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.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
Please tell me that none of those bone-heads on LKVM advocating that chroot should be 'root proof' haven't had any patches accepted!
/tmp), that is free of any setuid binaries, and without "useful" utilities like wget or curl that can make exploiting the system child's play. If your program runs inside of a chroot as a non-root user, and your chroot has no setuid binaries, and your kernel has no privilege escalation vulns, then you can be reasonably sure that nobody will break the chroot or achieve privilege escalation. Without a chroot, you would have to clear your entire server of setuid binaries and mode 7771 directories -- not to mention the potential for intentionally world-readable files that can lead to information exposure. Quite simply, a chroot prevents an arbitrary-execution vulnerability in bind (or other process) from exploiting a privilege escalation vulnerability in apache (or other process).
Of course chroot() doesn't do any good if a process inside of it is running as root. This is very well known. However, that doesn't make chroot() useless, it is still plenty useful. If you execute chroot() and then a seteuid(uid) where uid>0, then you prevent a hole/bug in your program from being exploited in a way that will allow file access/execution outside the chroot. That *is* a security advantage.
The point of "chroot security", cases where chroot is used to improve security, isn't to contain a malicious root user. The point is to prevent privilege escalation. You can create a chroot without any directories with mode 7771 privileges (a la
What some people think, apparently due to pure ignorance, is that chroot() is an end-all solution that will prevent even a root-owned process from accessing files outside the chroot, or worse, thinking that it protects the memory subsytem in any way. It doesn't. Even if the discussed patch was applied to the kernel, a root-owned process could still alter kernel memory, access raw devices, etc.
Improvements in ACLs under Linux minimize some of the needs for a chroot, other than the fact that a chroot is still much easier to configure and ACLs do not handle all of the use-cases that a chroot can solve. (and visa-versa, chroot cannot solve all of the problems solved by ACLs) Additionally, a chroot *and* ACLs can be used together for further-improved security.
Basically chroot was an early attempt at virtualization. It allowed one to keep servers separated and contained, which improved reliability and availability. It has a minor positive effect on security, but not really all that much. There is a good argument to be made for not using chroot since it increases the maintenance effort, which frequently results in chrooted servers being neglected which reduces security. As for myself, I avoid using it, due to the maintenance issues.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
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.
Do you even lift?
These aren't the 'roids you're looking for.
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.
When information is power, privacy is freedom.
> 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.
Democrat delenda est
Any discussion that revolves around whether or not chroot "is a security tool" is just another one of those meaningless semantic merry-go-rounds, and will never accomplish anything. We know what chroot does, and we know what it doesn't do. Whether or not it's deemed to be an official card-carrying security tool, it's undeniable that there are cases where it's useful, and it's likely that there exist programs that (a) use chroot appropriately and (b) are less vulnerable as a result. I don't care if it's a security tool or not, I care if it provides functionality that will make my code do what I need, and one of my needs is security. I'll bet some very talented programmers also use the assignment operator ("=") in code that needs to be secure, and I'll bet it sometimes plays a role in the code's functionality, part of which is being secure. Is it a security tool? Who could possibly care?
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?
"You think Windows is better, just because there isn't a public record of every chair Microsoft's heads throw at their employees?"
Fixed that for you.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
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 theNot incompetent. You can't blame admins who haven't been instructed properly, but you can certainly blame kernel developers who haven't clearly communicated what their tools are to be used for. Adrian ought to spend his time educating not insulting.
I'm rather weary of the "I have a bigger pen^H^H^H brain than you do" bullshit that goes on in IT.
Camping on quad since 1996.
Of course now that I'd done the simple search I find it coincidentally, everywhere.
Quack, quack.
It doesn't make sense. Using chroot(2) for security is like trying to fit a round peg into a square hole that it was never intended to go into.
It also doesn't make sense that certain inbound TCP ports are restricted to being bound only by root, but that's the reality we have to live with.
<Thought-experiment>
Wrap your mind around the fact that it is Microsoft Windows userland now that causes most of its insecurity. If you could cleanly separate Microsoft Windows userland and run it under an Open BSD kernel, it would still be insecure. Conversely, if you could run an Open BSD userland under a Microsoft Windows kernel, it most likely would be more secure (sans Microsoft programming and design errors).
</Thought-experiment>
Chroot will not and cannot defend against the ill-advised practice of running binaries ("trusted" or not) received off host. Yes, I'm also looking at you Mac OS X, which is otherwise a lovely system.
2. While operating a motor vehicle.
3. While dining at an expensive restaurant.
4. While dancing.
5. While urinating.
6. While defending yourself against a murder charge.
7. While picking fleas off a gorilla's back.
8. While seasoning a fine hamburger patty.
9. While being arrested.
10. While having sex.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
All you need to do now is go back three to four years and see if the search results come up with anything then.
Exactly, we are using chroot for our testing environment, it is much faster than virtual machines. The only two downsides are the shared resources (listening TCP ports, shared memory, shared kernel) and the bad security. The conflicting TCP ports can be resolved by NAT (iptables), the shared memory can be increased and the shared kernel version didn't cause any trouble (yet). Bad security isn't a real problem in a trusted environment.
A window lock will never keep out a thief. But it will make them go elsewhere, or decide it's not worth it. ... and every little helps!
If you're root you have a master key, so the lock has no meaning. But if you've not got your key yet it makes your attack a lot more obvious.
Without the lock the thief can make a tiny hole in the window and flip open the latch; once they're in they close the window and nobody can see the difference. With the lock the thief has no option but to smash the window, leaving lots of evidence that something is wrong. Likewise a computer attacker has to make themselves a lot more obvious if they want to get out of a chroot. They also have to know if another process will respond badly to a signal or if there's some IPC they can interfere with or a process they can attach with ptrace() or a local root exploit. They might have to wait around for the oppotunity to get to root or out of the chroot while all the time the logs build up.
So a chroot will discourage an attacker, just like window locks discourage a thief but they are not a security device because they don't actually add security they just strengthen the existing security a little
So what's wrong with chroot?