Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

When Not to Use chroot

CowboyNeal posted about 7 years ago | from the trust-no-one dept.

Security 407

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

cancel ×

407 comments

Sorry! There are no comments related to the filter you selected.

Then what is it for? (0, Insightful)

Anonymous Coward | about 7 years ago | (#20776357)

Next up ls is not for directory listings, and rm is not for removing files.

Re:Then what is it for? (5, Informative)

larry bagina (561269) | about 7 years ago | (#20776697)

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:Then what is it for? (5, Interesting)

soloport (312487) | about 7 years ago | (#20776761)

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.

misleading... (5, Informative)

onemorehour (162028) | about 7 years ago | (#20776359)

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.

Or is it? (4, Interesting)

phorm (591458) | about 7 years ago | (#20776395)

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.

Re:Or is it? (2, Interesting)

Niten (201835) | about 7 years ago | (#20776607)

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.

Any good sysadmin knows not to rely on a chroot jail to contain a process running as root. And if your MTA has to run as root, then it's a problem with the design of the MTA, not with the chroot mechanism. (If your MTA insists on running with root privileges, I highly recommend switching to Postfix if possible.)

Chroot is an excellent tool. But as with all security devices, it's up to the administrator to know precisely what it can and cannot do, rather than relying on it blindly. That's sort of what sysadmins are paid for.

In theory yes (2, Insightful)

renegadesx (977007) | about 7 years ago | (#20777133)

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.

Re:Or is it? (2, Informative)

TheRaven64 (641858) | about 7 years ago | (#20776627)

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.

For daemons that don't run as root (0)

benhocking (724439) | about 7 years ago | (#20776679)

Yes, however, for daemons that don't run as root, the user cannot use the chroot command. Per the man page: "This command can be run only by the super-user."

Re:For daemons that don't run as root (5, Informative)

TheRaven64 (641858) | about 7 years ago | (#20776739)

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.

Excellent explanation (1)

benhocking (724439) | about 7 years ago | (#20776785)

I was wondering how that statement made sense. Obviously, I've never used chroot. (Correctly or incorrectly.)

Re:Or is it? (1)

TheRaven64 (641858) | about 7 years ago | (#20776685)

And, by cwd() I, of course, mean chdir(). By the way, anyone using FreeBSD can set the kern.chroot_allow_open_directories sysctl to prevent chroot being called by any process which has open file descriptors outside the jail, which will block the discussed exploit. It will not, however, prevent any process with root privilege from creating a new device node pointing at the block device on which the root filesystem is mounted and accessing it this way, or accessing kernel memory to modify its process table entry directly. There are probably a hundred other ways of escaping from a chroot if you are root, but these are the first two that come to mind.

Re:Or is it? (1)

bfields (66644) | about 7 years ago | (#20776629)

The problem is that - for many root-running processes - running chroot has often been recommended as a security practice.

Reference? A quick google search for "bind chroot" finds several howto's explaining how to run bind under chroot as a non-root user. None that I can find suggest chroot and root.

Re:Or is it? (1)

esaul (686848) | about 7 years ago | (#20777239)

True that, but think it, - what was the original purpose for chroot? How did this "feature" come to be? Ever tried to update your glibc by hand? binutils? This is where one would get the most use of it. Given a chance won't you test something new before pitching?
People love chroot, and some insist on chrooting MTAs, Apache and others, and I am loving it (do what I say, not what I do)! I like this trend. It is not really about security. This is the K&R OOP principle of encapsulation creeping on from programming to system administration.

Re:misleading... (1)

QuantumG (50515) | about 7 years ago | (#20776439)

A process running as a regular user can break out too. There's a variety of tricks. Virtualization solutions are much more secure.

Re:misleading... (1)

onemorehour (162028) | about 7 years ago | (#20776521)

there are tricks that don't involve privilege escalation? I'd be curious to see what these are.

Re:misleading... (1)

QuantumG (50515) | about 7 years ago | (#20776585)

Obviously they involve privilege escalation.

Re:misleading... (2, Insightful)

onemorehour (162028) | about 7 years ago | (#20776649)

Then I don't see how this is different from saying that root privileges can escape from a chroot jail.

Re:misleading... (1)

QuantumG (50515) | about 7 years ago | (#20776765)

Well there's kernel exploits for a start.. but yeah, ok, close enough.

chroot, security and other uses (3, Informative)

jmorris42 (1458) | about 7 years ago | (#20777075)

> 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:misleading... (1)

Brandybuck (704397) | about 7 years ago | (#20776457)

That's the problem, you're assuming chroot is a jail. They serve two different purposes. If you need a jail, use a jail (or equivalent).

Re:misleading... (1)

hedwards (940851) | about 7 years ago | (#20776745)

Exactly, I thought chroot was for times like when you're compiling the OS for a live cd and need to install the binaries in the cd staging directory rather than in /.

Re:misleading... (0)

Anonymous Coward | about 7 years ago | (#20776485)

Breaking out of chroot is done via various pretty standard techniques, which can be blocked by patchsets like grsecurity [grsecurity.net] . Not perfect, but properly applied you're likely to be protected from most 0day exploit scripts.

Did someone say... (1)

markov_chain (202465) | about 7 years ago | (#20776531)

that a user at the root of the Linux tree exit out of a jail? The police are trying to locate a man that might be trying to cut his beard. Hopefully they will find him.

Re:misleading... (2, Interesting)

risk one (1013529) | about 7 years ago | (#20776633)

So is the point of chroot safety rather than security? Ie. used to circumvent the "don't do stuff as root, because mistakes can have bad consequences" thing? I'm not intimately familiar with chroot, but this is how I understand it. It's possible to break out of a chroot jail (therefore don't use it for security), but it's unlikely that you'll do so accidentally (therefore feel free to use it for safety).

Is that about right?

Re:misleading... (1)

fooDfighter (916234) | about 7 years ago | (#20776705)

The only purpose for chroot I've ever known is for testing, (ie. chroot into a dummy linux install and play with stuff) or to repair a broken linux install by booting from floppy/cd and chrooting into the mounted linux partition. I don't think I'd trust it for security and there are better solutions to making mistakes as root (such as frequent backups).

Re:misleading... (1)

risk one (1013529) | about 7 years ago | (#20776809)

I know that postfix runs chroot (in a lot of distro's anyway). I figured they had some solid technical reason for this, but it turns out they actually use this as asecurity mechanism (see here [postfix.org] ). They know that chroot jails can be broken out of, but they claim that 'every little bit helps'. My intuition says that 'every little bit helps' is not an effective way to think about security, though.

Re:misleading... (0, Troll)

Ice Station Zebra (18124) | about 7 years ago | (#20777139)

This is why I use qmail. After all, the RFC for smtp hasn't changed in how long, so why isn't postfix finished yet.

Re:misleading... (3, Informative)

NNKK (218503) | about 7 years ago | (#20776759)

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:misleading...Re:Asshole Stereotype (2, Insightful)

gerf (532474) | about 7 years ago | (#20776667)

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

Re:misleading...Re:Asshole Stereotype (5, Informative)

visualight (468005) | about 7 years ago | (#20776821)

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:misleading...Re:Asshole Stereotype (0)

Anonymous Coward | about 7 years ago | (#20776861)

The comment was directed at system administrators, not desktop users. You're safe :)

Re:misleading...Re:Asshole Stereotype (1)

gerf (532474) | about 7 years ago | (#20776953)

Thanks, as this was not explicitly said, I am confuzzed. It happens waaayyy too easily, I must say.

Re:misleading...Re:Asshole Stereotype (0)

Anonymous Coward | about 7 years ago | (#20777033)

You're doubly safe because Ubuntu does not by default have any open ports. This article is directed at administrators who run web servers that have processes that do things. Ubuntu Desktop does not do these things, so you're super safe, unless you download a virus and run it, a rare thing in the Linux world indeed.

Re:misleading...Re:Asshole Stereotype (0)

Anonymous Coward | about 7 years ago | (#20777017)

Please don't. The last thing Linux needs is a bunch of idiots whining every time they're offended by something on the internet. In fact, I don't think any OS needs that.

Re:misleading...Re:Asshole Stereotype (0, Troll)

evilviper (135110) | about 7 years ago | (#20777019)

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.

You think Windows is better, just because there isn't a public record of every screaming rant Microsoft's heads deliver to their employees?

As a beginner, you certainly shouldn't be mailing the Linux Kernel lists, and suggesting security methods...

Re:misleading...Re:Asshole Stereotype (5, Insightful)

Jah-Wren Ryel (80510) | about 7 years ago | (#20777031)

'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... (5, Insightful)

nine-times (778537) | about 7 years ago | (#20776795)

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.

Re:misleading... (2, Insightful)

mgkimsal2 (200677) | about 7 years ago | (#20776917)

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

Re:misleading... (0, Troll)

evilviper (135110) | about 7 years ago | (#20776999)

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.

No, what's stupid is suggesting that a mailing-list or forum full of unpaid experts should be compelled to answer your trivial questions is the 'retarded' part.

So you get to save a couple hours, not having to search the archives for the last 100Xs they answered the exact same question, and they get to give that 5 minute answer to you, and also the 100,000 people who ask that question after you, because they, too, didn't want to spend any of their own time looking for the answers themselves.

If you ask the experts, and don't get as much advice as you wanted, you're still better off than when you started. Insults aren't good, but of course I don't know that anyone was really insulted, as this is just one person's account of what happened... Some people have extremely thin skin, and will also often leave out the fact that they were spewing insults left and right when they didn't get the answer they wanted...

Re:misleading... (0)

Anonymous Coward | about 7 years ago | (#20777023)

methinks thou dos protest to much...

Re:misleading... (1)

Aladrin (926209) | about 7 years ago | (#20777081)

That's only 'insightful' if the list really -had- answered the question already. From his story, I'm going to assume they hadn't, didn't have the answer, and simply wanted to appear that they knew what they were talking about. If the answer was really that simple, it would have been easier to give him a link or just tell him how, rather than repeatedly insult him. Insulting him as well is optional.

No, he doesn't have the right to expect an answer from them, but he -can- expect a civil response, or no response at all if they can't be civil. I don't know what list it was, and I didn't really pay attention to the question other than that he wanted a secure FTP setup. It doesn't really matter, though, as being civil should be the standard, not the exception. All too many lists and forums yell first and help later.

Re:misleading... (1)

evilviper (135110) | about 7 years ago | (#20777157)

From his story, I'm going to assume they hadn't, didn't have the answer, and simply wanted to appear that they knew what they were talking about.

You're assuming a ridiculous amount of decidedly non-obvious facts...

If the answer was really that simple, it would have been easier to give him a link or just tell him how, rather than repeatedly insult him. Insulting him as well is optional.

People don't tend to maintain a list of links to every subject they've ever discussed. So somebody has to do the searching, rightfully it should be the one who wants to know the answer...

And also: No. Insulting someone is really much quicker and easier than posting a link of typing an answer... umm... you idiot.

but he -can- expect a civil response, or no response at all if they can't be civil.

Again, you're assuming that's what happened, as opposed to just what he SAID happened. I've seen several people on /. complaining about their experiences with mailing list XYZ, and gone through the trouble of looking the threads up in the archive, only to find people almost always VASTLY exaggerate their experiences, if not outright lie.

Re:misleading... (1)

nine-times (778537) | about 7 years ago | (#20777161)

No, what's stupid is suggesting that a mailing-list or forum full of unpaid experts should be compelled to answer your trivial questions is the 'retarded' part.

Ummm... I don't know how to explain this to you since you seem to be somehow impaired, but it was a HELP FORUM. It was a forum specifically set up so that people could ask those sorts of questions, it was posted in the right place, and I had already searched the forum and many others to see if the question had already been asked and answered. Not one single person in the forum was questioning whether it was appropriate to ask the question, but they were all just blowing me off anyway and calling names.

So what the hell is your problem? Seriously. I'm asking.

Re:misleading... (1)

evilviper (135110) | about 7 years ago | (#20777191)

If it's a true story, link to the forum, and the actual thread if at all possible. It would certainly make it easy for readers to form a non-biased opinion of what actually happened.

I've seen far too many examples where people vastly exaggerate their experiences.

Re:misleading... (0)

Anonymous Coward | about 7 years ago | (#20777063)

Use SFTP. It uses SSH internally, so communications are secure. Also, it only grants a user access he would have if logged in locally. Use that to your advantage.

Re:misleading... (0)

Anonymous Coward | about 7 years ago | (#20777091)

Do you have a link to your forum thread? I ask because I'm often on the other side of these questions, the one trying to at least occasionally provide answers, and your summary points to a fair amount of pathological behavior. First you asked about a specific method (jailing SFTP) when all you cared about was the general case (FTP-alike with secure authentication) but you didn't actually mention why you wanted this. Then you ask about using FTP with SSL, still not saying what your overall goal is. Only after all this do you mention the general goal, and I bet this was poorly phrased too. By this time they were probably pretty frustrated at your time-wasting antics and weren't really giving their full attention to solving your problems for free.

I do agree with your resentment of the term "incompetent", however. I think that should be reserved for people who are clearly unaware of their own limitations, such as those who constantly give bad advice that has the sound of coming from an expert, or those who are in a position of great responsibility without anything near the skills which are required for the position.

Re:misleading... (1)

thePsychologist (1062886) | about 7 years ago | (#20777101)

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.


This is a general thing: most people when they know something that other people obviously do not, they call those people incompetent or stupid, even though they are ignorant of many things that other people are not. People do it to make them feel better and compensate for their inadequacies. People who are very capable in a single area are especially known for this partially because their lack of self confidence drove them to that area of expertise in the first place.

A fate worse then death... (1)

newgalactic (840363) | about 7 years ago | (#20776371)

Documentation, NOOOOOO!!!!!!! ...it's a dirty job, but someone better do it.

FreeBSD Jails (4, Informative)

cstdenis (1118589) | about 7 years ago | (#20776423)

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.

Re:FreeBSD Jails (0)

TheNetAvenger (624455) | about 7 years ago | (#20776461)

This is also like protected processes in Vista, but in the FOSS world, people think it is DRM, when it is actually security and doesn't have anything to do with the Video protected path for HDCP...

So why should we expect anyone to understand security when they can't figure out simple differences and easily confuse security with DRM?

Re:FreeBSD Jails (2, Informative)

cstdenis (1118589) | about 7 years ago | (#20776575)

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:FreeBSD Jails (1)

BiggerIsBetter (682164) | about 7 years ago | (#20776733)

So pretty similar to Solaris Zones then?

it isn't for security? (0)

Anonymous Coward | about 7 years ago | (#20776487)

Well, what the living fuck is it for then? Just extra shit in the kernel, more hassle for admins?

"My code isn't broken, you're just stupid." is what this sounds like.

Not for security use? (3, Interesting)

kcbrown (7426) | about 7 years ago | (#20776489)

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.

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.

Re:Not for security use? (4, Informative)

cperciva (102828) | about 7 years ago | (#20776605)

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:Not for security use? (1)

EvanED (569694) | about 7 years ago | (#20776683)

2. Hard link /usr/bin/su to ~/usr/bin/su. (Yes, you can create hard links to files which you don't own.)

Preventable if ~ and usr are on separate file systems, but that still seems fragile.

4. chroot ~ /usr/bin/su root /bin/chmod 4555 /bin/sh

I would say that this could be as easily viewed as a problem with the implementation of chroot as a reason to not allow non-root users to chroot.

Re:Not for security use? (2, Interesting)

QuantumG (50515) | about 7 years ago | (#20776711)

Hard link /usr/bin/su to ~/usr/bin/su. (Yes, you can create hard links to files which you don't own.)
Yes, and there's the bug.. which hasn't been fixed for 40 years.

try for yourself:

$ id
uid=1000(you) gid=1000(you)
$ 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?

$ rm -f /bin/bash
rm: cannot remove `/bin/bash': Permission denied
$ rm -f foo
rm: cannot remove `foo': Operation not permitted

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

Re:Not for security use? (2, Informative)

e9th (652576) | about 7 years ago | (#20776813)

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:Not for security use? (2, Insightful)

evilviper (135110) | about 7 years ago | (#20776905)

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

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 /tmp to begin with, where the sticky bit is set on the folder, and only if /bin is on the same mount point as /tmp.

I can see how it would be a minor annoyance, not much of a bug.

Re:Not for security use? (5, Insightful)

kfstark (50638) | about 7 years ago | (#20776915)

$ 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:Not for security use? (1)

QuantumG (50515) | about 7 years ago | (#20776951)

actually, my recommendation would be to make ln /bin/bash foo fail.

No hardlinks to files you don't own.

Re:Not for security use? (1)

quenda (644621) | about 7 years ago | (#20777015)

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

Ah no, actually a hard link is just a directory entry pointing to the SAME i-node.
You knew that really?

Re:Not for security use? (1, Informative)

Anonymous Coward | about 7 years ago | (#20777123)

> 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:Not for security use? (3, Informative)

MSG (12810) | about 7 years ago | (#20776949)

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.

Re:Not for security use? (1)

QuantumG (50515) | about 7 years ago | (#20777047)

simply shows that you're ignorant of what the semantics are.
Or I forgot about the sticky bit. Thanks.

allowing them to create a link to it is not an inherent risk.
'cept it makes it looks like the owner of the file created it in that directory. What's even more neat is this:

$ ls -l bobs_file
-rw------- 3 bob bob 10815 2007-05-01 18:53 bobs_file
$ ln bobs_file /tmp/lock_bobs_quota
$ ls -l /tmp/lock_bobs_quota
-rw------- 3 bob bob 10815 2007-05-01 18:53 lock_bobs_quota

now when bob needs some space and he goes to rm -f bobs_file the link to the file will go away, but the file will hang around and unless bob looks in /tmp he'll have no idea why.

These are not security concerns, to be sure, but they are mischievous.

Re:Not for security use? (0)

Anonymous Coward | about 7 years ago | (#20776989)

another reason to have /tmp on its own partition with noexec set.

Re:Not for security use? (1)

Jah-Wren Ryel (80510) | about 7 years ago | (#20777115)

Uhhh, why is a regular user allowed to create a file owned by root?
A regular user is not allowed to create a file owned by root. You have created a hard link, it is only a directory entry in a directory you have permission to write to, and directory entries do not contain file ownership information, that is stored in the inode for the file. There is only one inode no matter how many hard links there are.

Awesome, the semantics of directory permissions are not even honored anymore.. anyone else smell a kludge here?
No. But I do smell a newbie ranter.

$ ls -ld /tmp
drwxrwxrwt 14 root root 69632 2007-09-27 21:25 /tmp/

See that 't' in the directory permissions on /tmp?
That's the sticky bit. When set on a directory, it means that only file owners and delete the directory entries for their files.

Take away the sticky bit and you will be able to delete the foo hard link just fine.

Re:Not for security use? (1)

Breakfast Pants (323698) | about 7 years ago | (#20776827)

Wrong; that exploit is only available because you chose to set up an insecure system by allowing a user into the wheel group.

Re:Not for security use? (1)

Harik (4023) | about 7 years ago | (#20777205)

you're the idiot - the exploit works because _IF NON ROOT USERS_ can call chroot, _THEY_ setup the <chroot>/etc/group and <chroot>/etc/passwd, so the (hardlinked, suid) copy of su sees the user copies. Notice how they get to pick the root password? Right. Now you get it. This is the "security" reason why a convienience/testing feature got made root-only.

Nothing Like... (1)

Techman83 (949264) | about 7 years ago | (#20776503)

the smell of flame war in the morning.

Nothing to see here, move along.

Duh. (3, Informative)

wilymage (934907) | about 7 years ago | (#20776507)

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:Duh. (1)

stox (131684) | about 7 years ago | (#20776573)

This hasn't been a problem in FreeBSD for many years:

Finally it should be noted that not all version of Unix are vulnerable to this attack. FreeBSD 4.x and above have a better chroot() system call. It can be made to fail if the process has any file descriptors open on a directory. This works by stopping the attack above which essentially works due to a file handle being open on a directory.

Re:Duh. (-1, Flamebait)

Cobralisk (666114) | about 7 years ago | (#20776687)

This hasn't been a problem in FreeBSD for many years:
That's because BSD is dead. Netcraft confirmed it.

Re:Duh. (1, Informative)

Anonymous Coward | about 7 years ago | (#20776591)

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:Duh. (1)

wilymage (934907) | about 7 years ago | (#20776983)

Interesting response, it will hopefully be modded informative. Things like mknod to create raw disk access or modifying kernel memory space do require root access. However, I think it's worth pointing out that there are methods that don't, such as following hardlinks (which continue to point outside the jail, unlike symlinks).

Sure, it requires some tardy system administration to have hardlinks like this in place, but it's not possible for the most moronic of admins to make this mistake with virtual machines, as an example.

Re:Duh. (3, Insightful)

nuzak (959558) | about 7 years ago | (#20776593)

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.

No, jails are for security (0, Flamebait)

kevmeister (979231) | about 7 years ago | (#20776513)

The correct answer is to use jail(8) for security. That's why they exist and what they are intended for. Does Linux have jails yet? Maybe you need to switch to a BSD based system.

Re:No, jails are for security (-1, Flamebait)

Anonymous Coward | about 7 years ago | (#20776551)

Nah, I like having all of my hardware work and not having to ever run cvsup. For any reason.

So take your BSD and shove it up your faggot ass you punk.

Re:No, jails are for security (1)

cstdenis (1118589) | about 7 years ago | (#20776643)

"having all of my hardware work..."

I guess you are a windows fan then.

I'll bite (1)

feld (980784) | about 7 years ago | (#20776663)

Where can someone show me the proper way to use a JAIL on Linux? Do we actually have that capability? And if not, why the hell not?

Re:I'll bite (1, Funny)

TheRaven64 (641858) | about 7 years ago | (#20776771)

I believe the correct procedure is to install this helper utility [daemonology.net] first.

Re:I'll bite (2, Informative)

larry bagina (561269) | about 7 years ago | (#20776877)

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.

Yeah, okay. (4, Insightful)

Anonymous Coward | about 7 years ago | (#20776533)

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.

Re:Yeah, okay. (1)

EvanED (569694) | about 7 years ago | (#20776709)

And RAID isn't for safety of your data either, hey?

Actually, to some extent, this is true. RAID is mostly there for speed and to eliminate downtime when the hardware breaks.

Backups are for the safety of your data, not RAID, and RAID can't take the place of backup.

lacing up my track shoes (1)

v1 (525388) | about 7 years ago | (#20776623)

"chroot manages security like DRM manages your digital rights".

ok I better run now. Give me a head start, wouldja?

Chroot as a non-security tool (5, Insightful)

BurningSpiral (413606) | about 7 years ago | (#20776635)

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:Chroot as a non-security tool (2, Insightful)

LSD-OBS (183415) | about 7 years ago | (#20776775)

I must be oldschool. What you described is the only thing I've ever used chroot for.

Re:Chroot as a non-security tool (3, Informative)

xenocide2 (231786) | about 7 years ago | (#20777185)

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.

Who is he anyway? (0, Flamebait)

ByTor-2112 (313205) | about 7 years ago | (#20776671)

Just because someone has written some code and has poor personal hygiene doesn't mean what they think is the end-all of a topic, much less that everything that comes out of their mouth is some fantastic headline.

Genius? (0)

Anonymous Coward | about 7 years ago | (#20776677)

Geez guys. chroot was not designed as a security tool even though you may be using it as such. Don't be calling people names because you don't know as much as you think you do. chroot is for exactly what it's named for changing the root directory.

For instance, say you are using Fedora and muck up your boot loader so the system doesn't boot. Usually you boot the rescue CD, mount the root file system under /mnt/sysimage. From there you can "chroot /mnt/sysimage" and then it will be much like you booted directly from the hard drive (there are a few other things that you should do as well) and can run any command from the hard drive as if you booted from the hard drive. For instance, you can now "vi /etc/grub.conf" or reinstall your boot loader "grub-install /dev/sda", etc.

Another example is you can build a root file system under a subdirectory and then chroot to that system image to test things as if you booted that system image before writing it to CD.

chroot IS an effective layer (2, Insightful)

sdsucks (1161899) | about 7 years ago | (#20776701)

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.

Not suprising, Linux avoid pathname-based security (1)

salahx (100975) | about 7 years ago | (#20776751)

The Linux developers generally looked down pathname-based security (for what I think are good reasons). That's one of the reasons like SELinux is venerated and AppArmor is snubbed. So this is no surprise. Especially given the VFS and namespace games you can play in Linux (bind mounts, slave mounts, /proc ).

So this is no surpise. chroot() is certainly useful, but not for keep root in jail; use SELinux for that.

What the hell is wrong with these people? (4, Insightful)

Epistax (544591) | about 7 years ago | (#20776777)

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.

Re:What the hell is wrong with these people? (2, Insightful)

smcn (87571) | about 7 years ago | (#20777071)

I think it's more like all unemployed programmers become assholes, no matter how trivial their "expertise". Case in point: most of the developers and community of WoWAce, a set of libraries for World of Warcraft mod development. Any question or suggestion made on their wiki is immediately met with responses from "the experts" telling you why you don't need what you think you do, and why you're an idiot for wanting such. I'm quite positive many development-related forums exist solely for the purpose of torturing "newbs".

mean (0)

Anonymous Coward | about 7 years ago | (#20776783)

kernel hackers seem to be mean :( at least in my experience...

before you reply, please consider that it would take as much effort to go out of your way to be police as going out of your way to be mean and talk down to someone

Oversimplified... (2, Informative)

evilviper (135110) | about 7 years ago | (#20776823)

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.

CHROOT Manual says it all : (1)

zukinux (1094199) | about 7 years ago | (#20776849)

man chroot :
[codee]
CHROOT(1)                        User Commands                       CHROOT(1)
NAME
       chroot - run command or interactive shell with special root directory
SYNOPSIS
       chroot NEWROOT [COMMAND...]
       chroot OPTION
DESCRIPTION
       Run COMMAND with root directory set to NEWROOT.
       --help display this help and exit
       --version
              output version information and exit
       If no command is given, run ``${SHELL} -i'' (default: /bin/sh).
AUTHOR
       Written by Roland McGrath.
[/code]

Well.. the manual sums it all up.

Are they serious? (4, Insightful)

GiMP (10923) | about 7 years ago | (#20776857)

Please tell me that none of those bone-heads on LKVM advocating that chroot should be 'root proof' haven't had any patches accepted!

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 /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).

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.

Overtaken by virualization (3, Interesting)

flyingfsck (986395) | about 7 years ago | (#20776867)

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.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?