Slashdot Mirror
When Not to Use chroot
Hyena writes "Linux guru Alan Cox is quoted as saying 'chroot is not and never has been a security tool' in a KernelTrap article summarizing a lengthy thread on the Linux Kernel mailing list. The discussion began with a patch attempting to 'fix a security hole' in the Unix chroot command, trying to improve the ability of chroot to contain a process. When it was pointed out that people have been using chroot as a security tool for years, another kernel hacker retorted, 'incompetent people implementing security solutions are a real problem.' A quick search on the terms 'chroot+security' quickly reveals that many people have long thought (wrongly) that chroot's purpose was for improving security."
This summary is truly and terribly misleading--the discussion simply says that a root user can break out of a chroot jail. Is this news? chroot can still be effectively used to contain processes that do not run as root.
The problem is that - for many root-running processes - running chroot has often been recommended as a security practice. This has often been the recommendation of the daemon authors, in the documentation, as a way to improve security.
I think that this was once (or may currently be) the case with bind and various MTA's. Standard practice for many daemons now is to start as root and fork as another non-privileged user, but not every daemon has this option.
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.
If chroot didn't require root privileges, the following exploit would be possible:
/usr/bin/su to ~/usr/bin/su. (Yes, you can create hard links to files which you don't own.) /bin/sh, /bin/chmod, and the necessary libraries to the corresponding places under ~. /usr/bin/su root /bin/chmod 4555 /bin/sh
1. Create ~/etc/master.passwd with an empty root password.
2. Hard link
3. Copy
4. chroot ~
5. ~/bin/sh is now an unrestricted root shell.
Tarsnap: Online backups for the truly paranoid
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.
Actually, Bill Joy invented chroot as a hack to use a custom /usr/include directory in a compiler that didn't support alternate include paths.
Do you even lift?
These aren't the 'roids you're looking for.
Just because you can only run a command as a superuser doesn't mean that all of the child processes of that command have to be run as the superuser. If this were the case, since init runs as root you would not have a multiuser system.
I am TheRaven on Soylent News
https://portal.mytesting.org:8080/ (including)
* tinyHTTP (AppWeb, Apache, etc.)
* SQLite (MySQL, Postgres, etc.)
* [chroot-path-0]/www/html/*
* Other ([chroot-path-0]/usr/lib, [chroot-path-0]/bin, etc.)
and repeat...
https://my-test-env.org:8081/ https://my-test-env.org:8082/ https://my-test-env.org:8083/ https://my-test-env.org:8084/ Next, bind
Now you have 5 chroot'ed web environments to help your test team (of 5) speed up Alpha testing. May be fraught with bad security? That's not the point.
Do all OS developers become assholes? I've done a lot with VxWorks and I hope I don't become as twisted as these folk. I better just stay away from authoring my own kernel.
I think his comment was directed specifically at people who do not have enough understanding to implement a security solution on linux but think they do. Would the same comment coming from an official MS authority on security make you not want to use Vista?
Anyway, I do understand the perspective behind your reaction, but it doesn't fit in this specific case.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
Please tell me that none of those bone-heads on LKVM advocating that chroot should be 'root proof' haven't had any patches accepted!
/tmp), that is free of any setuid binaries, and without "useful" utilities like wget or curl that can make exploiting the system child's play. If your program runs inside of a chroot as a non-root user, and your chroot has no setuid binaries, and your kernel has no privilege escalation vulns, then you can be reasonably sure that nobody will break the chroot or achieve privilege escalation. Without a chroot, you would have to clear your entire server of setuid binaries and mode 7771 directories -- not to mention the potential for intentionally world-readable files that can lead to information exposure. Quite simply, a chroot prevents an arbitrary-execution vulnerability in bind (or other process) from exploiting a privilege escalation vulnerability in apache (or other process).
Of course chroot() doesn't do any good if a process inside of it is running as root. This is very well known. However, that doesn't make chroot() useless, it is still plenty useful. If you execute chroot() and then a seteuid(uid) where uid>0, then you prevent a hole/bug in your program from being exploited in a way that will allow file access/execution outside the chroot. That *is* a security advantage.
The point of "chroot security", cases where chroot is used to improve security, isn't to contain a malicious root user. The point is to prevent privilege escalation. You can create a chroot without any directories with mode 7771 privileges (a la
What some people think, apparently due to pure ignorance, is that chroot() is an end-all solution that will prevent even a root-owned process from accessing files outside the chroot, or worse, thinking that it protects the memory subsytem in any way. It doesn't. Even if the discussed patch was applied to the kernel, a root-owned process could still alter kernel memory, access raw devices, etc.
Improvements in ACLs under Linux minimize some of the needs for a chroot, other than the fact that a chroot is still much easier to configure and ACLs do not handle all of the use-cases that a chroot can solve. (and visa-versa, chroot cannot solve all of the problems solved by ACLs) Additionally, a chroot *and* ACLs can be used together for further-improved security.
$ ls -l
-rwxr-xr-x 1 root root 700560 2007-04-11 09:32
$ ln
$ ls -l foo
-rwxr-xr-x 2 root root 700560 2007-04-11 09:32 foo
Uhhh, why is a regular user allowed to create a file owned by root? Apparently, you don't know what a hard link is.
You haven't created a file owned by root. You've created an i-node pointing to the data blocks of a file owned by root.
If root were to rm
Your way, I could do the following on a file with 600 permission:
cd
ln
chmod 666 mine
cat mine
Nice and easy way to get around a 600 permission.
The behavior is correct, not a bug.
Regards,
--Keith
Man, things like this make me want to NOT switch to Linux... Even though I had a better experience with Ubuntu that I did Vista. What's your problem with that statement?
It's absolutely true and it is not limited to linux.
Let's take it a few more steps further as an example: 'incompetent people designing bridges are a real problem.'
'incompetent people performing surgery are a real problem.'
'incompetent people running the government are a real problem.'
Do you have a problem with any of those statements?
If you don't even know what chroot() is, then you are not the target of the man's complaint.
When information is power, privacy is freedom.
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?
http://blogs.sun.com/chrisg/tags/chroot
Dr. Marshall Kirk Mckusick, private communication: ``According to the SCCS logs, the chroot call was added by Bill Joy on March 18, 1982 approximately 1.5 years before 4.2BSD was released. That was well before we had ftp servers of any sort (ftp did not show up in the source tree until January 1983). My best guess as to its purpose was to allow Bill to chroot into the2. While operating a motor vehicle.
3. While dining at an expensive restaurant.
4. While dancing.
5. While urinating.
6. While defending yourself against a murder charge.
7. While picking fleas off a gorilla's back.
8. While seasoning a fine hamburger patty.
9. While being arrested.
10. While having sex.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
> Apparently, you don't know what a hard link is.
/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).
/bin/bash foo
/tmp:
/tmp /bin/bash foo
/tmp /home/zoltan /home/zoltan /tmp
/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.
>
> 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
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
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
zoltan@gep:~> cd
zoltan@gep:/tmp> ln
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
drwxr-x--- 114 zoltan users 16248 2007-09-28 14:23
drwxrwxrwt 32 root root 3176 2007-09-28 14:25
The
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.