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."
Next up ls is not for directory listings, and rm is not for removing files.
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 explanation of that exploit is a good one, but it still requires root.
Isn't it just easier to remount the device?
News flash: root can break security. World ends at 10:00. Film at 11.
Done with slashdot, done with nerds, getting a life.
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.
Then I don't see how this is different from saying that root privileges can escape from a chroot jail.
'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.
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.
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.
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:
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.
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.
ln doesn't create files, just POINTERS to them. Creating a link to bash, which was owned by you, would presumably allow to modify the contents of bash, owned by root.
And that trick only works in
I can see how it would be a minor annoyance, not much of a bug.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
$ ls -l
-rwxr-xr-x 1 root root 700560 2007-04-11 09:32
$ ln
$ 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
Your way, I could do the following on a file with 600 permission:
cd
ln
chmod 666 mine
cat mine
Nice and easy way to get around a 600 permission.
The behavior is correct, not a bug.
Regards,
--Keith
No, you can't actually have that. 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.
Honestly, I've had the same problem, and what you're asking for is something that would benefit many people. It's just that this probably won't come about in the 'open source' development world because it's a pretty non-sexy problem, and is moderately low-level to deal with (sockets, ssl, etc.)
creation science book
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.
I agree that you shouldn't be running something like an MTA at a root level but like the above said, not every daemon has an option of being run at a lower level.
Sure its not good practice but if you need something working now you are not going to wait for the developers to change the code: especially if they have no intention on doing so.
Developers of many high level process I think have relied on chroot as a crutch, its more than just "up to the administrator" its more so up to the dev's to give you the option of not having to run the process as root in the first place.
Make SELinux enforcing again!
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?
Can't you do something like this with Apache?
It's not as straightforward to configure as SlimFTP seems, but it's a lot more flexible, and it's available.
Not 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.
Just because he set himself up for it doesn't mean you have to bite. Be gracious to people, even when they're wrong and you're right (or try to, at least)... it makes the world a better place.
"16MB (fuck off, MiB fascists)" - The Mighty Buzzard
Why is this so hard to believe?? #Linux on efnet at one time was horrible for this type of behaviour. There were a number of people in there who thought they were gurus (and had channel op status which went straight to their heads) and then when someone came in with a question they didn't know the answer to, they'd insult the guy and question his motives rather than just staying silent or admitting they didn't know the answer.
One instance in particular was a fellow who joined and asked if there was a way to get his new 3D video card working in Linux (I can't recall the brand/model, but it was around the ATI Rage Pro era, quite some time ago). Instead of saying "no idea" or "sorry, that just won't work", he was met with ridicule. "Why the hell do idiots buy brand new 3D cards and expect them to work in Linux, blah blah blah". In most cases, if the victim tried to defend his actions, he was just kicked and banned. Real mature. People like this are NOT helpful and the community would be better off if they'd simply fuck off and die.
All you need to do now is go back three to four years and see if the search results come up with anything then.
No, you don't have to be an "all-knowledgeable ubergeek", but if you're going to discuss security in a technical forum you should enter into it with some level of knowledge that grants you entry. People who operate at level 10 don't want to hold people's hands through levels 1 through 3 all the time, they want to discuss level 8 through 12 problems to broaden their own understanding. So find yourself a forum more appropriate to your level of expertise (a classroom might be a good start) and move up when you're ready.
If you don't want to spend all that time furthering your education and developing your skills you could atleast use some basic research abilities and garner some knowledge on the subject so you can ask pointed questions about various implementations rather than generalities about what you could do.
For the record, you don't like the "ubergeek" approach - well on the flip side of the coin people who have studied, researched and practiced computer/network administrative security for years (decades) don't appreciate every newbie firing a distro onto a spare partition and considering themselves "administrators". For the record, it's thousands/millions of your type who set up inherently insecure servers who contribute greatly to the spread of malware on the Internet through open proxies and relays, so there's a little bit of ire on the other side of the fence.
So if you're going to unleash your services on the open Internet, please, get some education first, open ports second.
BD Phone Home!
Shameless plug. Like you weren't expecting it.
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
Of course I'm assuming he isn't lying here. If you simply assume everyone's lying, there'd be no point in ever responding.
As for 'they should be the one to search'... Of course they should. But then, most people that can type without using contractions like 'ur' know that, and do. The problem is that if you only have a need, and no idea how to solve that need, what do you search for? Quite often the 'obvious' solution has a non-obvious name. He assumed that 'secure ftp' would be what he wanted. It wasn't what he wanted, though, and they insulted him for it. It would have been my first guess, too.
In my experience, when people complain about the uncivil responses they've gotten, they really did get them, deserved or not. If he's an ass, there's no need for them to be asses, too. That's what moderators are for. People that get no response generally complain about that, instead.
"If you make people think they're thinking, they'll love you; But if you really make them think, they'll hate you." - DM
"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."
With respect to technology, one is incompetent if that individual is unable to bring appropriate knowledge or skill to bear regarding a specific task. As for the prerequisite of being an omnipotent transnerd, I find your logic sadly off base. That would be akin to whining, "I can't have beef so I MUST have fish!" What about chicken? Stop the black and white thinking.
"If you can't, please refrain from name-calling because they want to do something that you can't figure out how to accomplish."
I almost was rendered incontinent while reading this statement, esspecially after the obvious hurt and angry statement, "all-knowledgeable ubergeek," above.
"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."
More anger? I think that you want a toaster. You know, press the button, and poof! Toast. Linux is NOT Windows or any other typical one-stop-shopping system. In its early days, you needed to understand DOS, and how to manage your system in Windows, but over time it's been streamlined to appeal to the kiosk-seeking, text-messaging, instant-gratification-needing, pseudo-efficiency-requiring brat. (Substitute "boss," "manager," or "teenager" here.)
If you wish to help with the effort of easing people's use of essentially free systems, then roll up your sleeves, learn the inner workings, and participate in development. If not, at least take the time to learn how to manage your system in a safe and effective manner. After all, do you simply drive your car until it overheats, seizes, or runs out of gas? Or do you take the time to ensure it has enough antifreeze, oil, and gas?
Pardon the brusqueness of my post, but I am rather hurt by the perjorative comments of the self-entitled, whose lack of patience in taking time to even attempt to understand the barest mininum regarding their own system, demonstrates clear incompetence.
Riposte!
-v
So what's wrong with chroot?
Did you really read the exchange? I mean, from a perspective not blurred by a glaze of sympathetic indignation?
makjls's cardinal sin was not asking a question in ignorance. The true error was arguing with knowledgeable people from a position of ignorance.
Alan Cox didn't get snippy until the Peanut Gallery began to presume they understood the rationale for chroot(2) better than he did.
Really, folks, ire is no substitute for understanding. Argue from a false presumption ("chroot is a security tool") and you will always lose, and make everyone involved look like jerks in the process.
I've been there, on the vehement-but-wrong side of the argument. (With Eric Raymond, if you can believe it.) I've had to publicly apologize. It's still out there for all digital eternity, thanks to Google Groups. (No, I'm not citing the URL. I use a pseudo on /. for a reason)
Truly, truly, when you approach acknowledged experts on a subject with a concern, don't get offended if they don't agree with you. Odds are good that they're right, and you might learn something if you listen instead of raising your voice.
Welcome to the Panopticon. Used to be a prison, now it's your home.