When Not to Use chroot

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

misleading...

[onemorehour]

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

Or is it?

[phorm]

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:

[Niten]

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

Re:

[kestasjk]

I'm one of the people who, up until now, thought that chroot was for security (Luckily I've never had to rely on it though).
In OpenBSD chroot is used to sandbox the web server, and as someone else pointed out the documentation often encourages people to chroot daemons. Also similar software like Solaris containers and FreeBSD jails, which do pretty much the same thing as chroot, actually are for security (pretty much exclusively in the case of jails, not exclusively in the case of containers).

Also you'l

Re:Or is it?

[h4rm0ny]

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

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

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

Re:Or is it?

[Rigrig]

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

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

Re:

[TheRaven64]

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

Re:

[TheRaven64]

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

Re:

[dfn_deux]

Some of this is patched up in gr security [grsecurity.net] patched versions of the linux kernel.

* No attaching shared memory outside of chroot * No kill outside of chroot * No ptrace outside of chroot (architecture independent) * No capget outside of chroot * No setpgid outside of chroot * No getpgid outside of chroot * No getsid outside of chroot * No sending of signals by fcntl outside of chroot * No viewing of any process outside of chroot, even if /proc is mounted * No mounting or

Re:

[dfn_deux]

Grrrr.... submit!=preview, sorry about the lack of proper linebreaks there...

Re:For daemons that don't run as root

[TheRaven64]

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

# chroot directory su nobody daemon

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

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

Excellent explanation

[benhocking]

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

Re:

[SL Baur]

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

Re:

[MobyDisk]

You're reply demonstrates the very complaint many posters are making, and the issue with the article:

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.

You say that chroot isn't good, then make a cool analogy, but don't actually explain why it is wrong. That analogy doesn't explain to anyone what is wrong with chroot. You then go off on a totally unrelated tangent about Windows security and TCP ports.

So what's wrong with chroot?

Re:

[VGPowerlord]

Of course, that causes a problem if the service in question needs to listen on a port < 1024, on only root can bind those... which makes me wonder why non-essential services such as httpd have low port numbers.

You can get around that by having it listen on a higher port number and having the kernel reroute packets, but that gets messy if you have to do it for a bunch of services.

Re:

[bfields]

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:

[QuantumG]

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

Re:

[onemorehour]

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

Re:

[QuantumG]

Obviously they involve privilege escalation.

Re:

[onemorehour]

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

Re:

[QuantumG]

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

chroot, security and other uses

[jmorris42]

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

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

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

Re:

[QuantumG]

Only if it can get access to a broken SUID program, etc.

Or kernel exploits.

Re:

[Brandybuck]

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:

[hedwards]

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:

[risk one]

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

[NNKK]

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

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

Re:

[SirSlud]

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.

What a succinct way of putting it.

Re:

[gmack]

Security is more than just the ability to gain root on a machine.. Qmail has good security in that regard however the ease of which it can be used for reflector spam (spam with bogus return address) means it's unusable without addon patches.

I used to use Qmail for everything until spammers started to fill my mailq with bounces.. now it's postfix for everything.

Re:misleading...Re:Asshole Stereotype

[gerf]

'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

[visualight]

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

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

Re:misleading...Re:Asshole Stereotype

[Jah-Wren Ryel]

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

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

What's your problem with that statement?
It's absolutely true and it is not limited to linux.

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

'incompetent people designing bridges are a real problem.'

'incompetent people performing surgery are a real problem.'

'incompetent people running the government are a real problem.'

Do you have a problem with any of those statements?

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

Re:misleading...Re:Asshole Stereotype

[bfields]

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

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

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

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

Re:

[gerf]

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

Re:misleading...Re:Asshole Stereotype

[VGPowerlord]

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

Re:misleading...

[nine-times]

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

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

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

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

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

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

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

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

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

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

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

Re:

[mgkimsal2]

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

Re:

[TerranFury]

I too have wanted the exact same thing.

In fact, it is starting to bother the heck out of me that servers rely on filesystem permissions to begin with, and I'm starting to think that it's something Unixes simply do wrong. Isn't it a security risk? Why do we let a user roam free around a drive, and hope that we set our permissions strictly enough everywhere?

Simply, I see no reason why an FTP or SFTP server needs to be tied to the filesystem at all. Why are FTP permissions associated with the files; the

Re:

[DougWebb]

Can't you do something like this with Apache?

• You can map URL paths to filesystem directories (separate URL path for each user)
• You have all sorts of ways to do user authentication and authorization (your users aren't system users)
• You can control permissions for GET, PUT, DELETE, etc separately (very fine-grained permissions)
• HTTP gives you browsing and retrieval, WEBDAV gives you a virtual filesystem, other protocol modules are available.

It's not as straightforward to configure as SlimFTP seems, but it

Re:

[uglyduckling]

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

Don't be silly, there are open source developers producing and using open source software in 1001 different scenarios. Many people are using Linux

*cough*

[msimm]

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

Re:

[thePsychologist]

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

Re:

[Phroggy]

Here's the answer to your question:
http://www.minstrel.org.uk/papers/sftp/

You'll need to compile your own version of OpenSSH. I'm running two instances of sshd, the default one that I can log into for administration and a hacked one for users (not on the same interface/port, obviously). I mostly followed the instructions from that page, but with this setup I don't need to use his crazy hack that uses /./ in the user's home directory (which could interfere with other things), so I applied this pa

Possible solutions

[SanityInAnarchy]

There's not likely to be anything really simple, depending on what kind of functionality you're offering.

You could do ssh access, without necessarily sftp (KDE's fish works with scp, I think), and deny them an actual login shell -- only allow sftp (or scp, or whatever). You could then block access to the rest of the filesystem with Unix file permissions or ACLs. Most things that they could access either aren't dangerous or are only visible to root (and maybe the file owner).

It's not easy, but consider: Ther

Re:

[Blkdeath]

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.

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

Re:

[Aladrin]

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 res

Re:

[evilviper]

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,

Re:misleading...

[nine-times]

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

Weren't you the one who just asked me elsewhere to post a link to the thread I was referring to?

Re:

[Aladrin]

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 wa

Re:

[nine-times]

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

Re:

[evilviper]

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:

[nine-times]

This happened 3-5 years ago on a forum that I never revisited because the people were so utterly rude. It would take my hours to find the thread, assuming it's even still available.

But my karma is generally good here, and you have access to my post history if you want to review it. Of all the things that people could accuse me of, no one who knows me would accuse me of being impolite when unprovoked or even particularly hot-tempered when provoked. I know lots of people are rude, but I'm almost always (a

Re:

[evilviper]

Let's see... In your first post you called random people "retarded" and then you unprovokedly called me "somehow impaired."

I think I'll reserve judgment on just how incredibly polite you are.

Besides, that was only one of the points I brought up. I'm not going to take the rest of your assertions on faith, either.

Re:

[zippthorne]

If they don't know the answer and don't have any desire to help him, what gives them the right to call him a moron? I mean, wouldn't it be easier to just say, "You can't do that with the tools available, and none of us are interested in making tools that would. You're on your own on this, so good luck." Or, y'know, not said anything at all?

Re:

[idontgno]

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 w

FreeBSD Jails

[cstdenis]

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

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

Re:

[BiggerIsBetter]

So pretty similar to Solaris Zones then?

Not for security use?

[kcbrown]

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?

[cperciva]

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

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

Re:

[QuantumG]

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

Re:

[e9th]

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

Remove the sticky bit from /tmp & try again.

Re:

[evilviper]

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?

[kfstark]

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

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

Apparently, you don't know what a hard link is.

You haven't created a file owned by root. You've created an i-node pointing to the data blocks of a file owned by root.

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

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

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

Nice and easy way to get around a 600 permission.

The behavior is correct, not a bug.

Regards,

--Keith

Re:

[QuantumG]

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?

[kocsonya]

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

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

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

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

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

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

The reason for that strange behaviour is this:

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

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

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

Re:Not for security use?

[MSG]

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

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

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

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

Re:

[QuantumG]

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 hav

Re:

[Jah-Wren Ryel]

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

Re:

[QuantumG]

No. But I do smell a newbie ranter.

Oh FUCK OFF. Can't a guy *forget* something now and then?

Re:

[Jah-Wren Ryel]

Oh FUCK OFF. Can't a guy *forget* something now and then?

Don't be so smug in your posts and you won't get flamed when you make a mistake.
You set yourself up for it. It's not like I was the only one to bite.

Re:

[QuantumG]

How about just not being an asshole about it? Seriously.. you're like a bunch of wolves. Just because you have no confidence in anything you say doesn't mean the rest of don't.

Re:

[bigstrat2003]

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.

Re:

[Jah-Wren Ryel]

So you're in the US? I go there 5 times a year man.
Drop me an email, we'll arrange a meet.

Let me know when you get to Denver, no reason to do it in email.
Of course you would be an idiot to show.
You have no idea how many local gangbangers and thugs want to give you a beat-down for your lame unix skillz.
They fuckin' hate people who can't use the sticky bit right.

Re:

[Breakfast Pants]

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

Re:

[Harik]

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.

Re:

[Phroggy]

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

What the hell are you talking about?

Duh.

[wilymage]

This isn't news.

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

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

Re:

[stox]

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.

[nuzak]

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.

Yeah, okay.

[Anonymous Coward]

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.

lacing up my track shoes

[v1]

"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

[BurningSpiral]

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

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

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

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

Re:

[LSD-OBS]

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

Re:Chroot as a non-security tool

[xenocide2]

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

chroot IS an effective layer

[sdsucks]

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.

What the hell is wrong with these people?

[Epistax]

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:

[smcn]

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 tortu

Re:

[Per Abrahamsen]

I see it mostly from the other side, a few users who ask for something that makes no sense, and when you explain that it makes no sense they get extremely rude. It sounds like you are a MMORPG player, and judging from the fora for those they are among the absolutely worst users. They seem to be convinced that the whole world (virtual and real) revolves around them, and that every aspect of the game should satisfy their immediate desires.

Anyone writing free software for that community have my sympathy.

[ Th

Re:

[Epistax]

No, they'll just do it implicitly along with many other things. Passive aggression serves to antagonize and make others A) feel bad, B) feel bad for feeling bad, and C) Look bad to others when being explicit.

Sorry, when but when I read or hear things implicit, they come out as screaming explicit. That particular conversation would be no less civil if laced with expletives and "your mom" comments.

Oversimplified...

[evilviper]

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

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

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

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

Are they serious?

[GiMP]

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

[flyingfsck]

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.

chroot neither is nor isn't a security tool

[drfireman]

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?

The correct word would have been ignorant

[lena_10326]

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.

When not to use chroot

[c0d3h4x0r]

When Not to Use chroot

1. While trying to get a date.
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.

Re:Then what is it for?

[larry bagina]

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

Citation

[BobKagy]

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

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

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

Re:Then what is it for?

[soloport]

What's it for?

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

and repeat...

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

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

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

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

Next, bind /proc to all 5. Then make a script to easily update them from SVN. Done.

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

Re:

[TheRaven64]

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

Re:

[larry bagina]

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

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

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