Slashdot Mirror
When Not to Use chroot
Hyena writes "Linux guru Alan Cox is quoted as saying 'chroot is not and never has been a security tool' in a KernelTrap article summarizing a lengthy thread on the Linux Kernel mailing list. The discussion began with a patch attempting to 'fix a security hole' in the Unix chroot command, trying to improve the ability of chroot to contain a process. When it was pointed out that people have been using chroot as a security tool for years, another kernel hacker retorted, 'incompetent people implementing security solutions are a real problem.' A quick search on the terms 'chroot+security' quickly reveals that many people have long thought (wrongly) that chroot's purpose was for improving security."
Next up ls is not for directory listings, and rm is not for removing files.
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.
Documentation, NOOOOOO!!!!!!! ...it's a dirty job, but someone better do it.
The problem is that - for many root-running processes - running chroot has often been recommended as a security practice. This has often been the recommendation of the daemon authors, in the documentation, as a way to improve security.
I think that this was once (or may currently be) the case with bind and various MTA's. Standard practice for many daemons now is to start as root and fork as another non-privileged user, but not every daemon has this option.
FreeBSD has a system called jails that do provide the security people are looking for in chroot. In addition to doing a chroot, they also prevent processes from seeing each other and can restrict network functionality.
Its like a virtual machine, but shares the same kernel (with restrictions) so there isn't the performance of full emulation.
1984 was not supposed to be an instruction manual.
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 improving security, huh?
OK, genius, then explain why chroot() requires root privileges (or chroot capability) to execute.
It's only in the context of security that such a restriction makes any sense at all.
Use 'slashdot stuff' in the subject line in any email you send me if you want to get past the spam filter.
the smell of flame war in the morning.
Nothing to see here, move along.
# cat
Damn, my RAM is full of cats. MEOW!!
This isn't news.
For those of you who weren't aware how easy it can be to break out of most chroots, here's a good description of a common process:
http://www.bpfh.net/simes/computing/chroot-break.html
The secret to creativity is knowing how to hide your sources. -- Albert Einstein
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.
Kevin Oberman, Network Engineer, Retired
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.
Tsunami -- You can't bring a good wave down!
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.
"chroot manages security like DRM manages your digital rights".
ok I better run now. Give me a head start, wouldja?
I work for the Department of Redundancy Department.
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.
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?
'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.
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.
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.
/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.
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
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.
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."
Ben Hocking
Need a professional organizer?
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.
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.
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.
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
I was wondering how that statement made sense. Obviously, I've never used chroot. (Correctly or incorrectly.)
Ben Hocking
Need a professional organizer?
I think his comment was directed specifically at people who do not have enough understanding to implement a security solution on linux but think they do. Would the same comment coming from an official MS authority on security make you not want to use Vista?
Anyway, I do understand the perspective behind your reaction, but it doesn't fit in this specific case.
Samsung took back my unlocked bootloader because Google wants me to rent movies. They're both evil.
It's terribly oversimplified to say that chroot is useless. What's stupid is to chroot a process running as root. Most programs that have the built-in ability to chroot themselves (eg. Apache) immediately drop root privileges and drop to a non-privileged account.
That said, even done properly chroot really only provides a little protection, and only in the case of horribly configured systems... IMHO, the sole benefit of chrooting a process is that anyone who successfully breaks-in can't execute SUID/SGID applications located elsewhere on the filesystem, which very, very commonly have security holes. Proper use of either sudo, or setting-up groups that are the only ones allowed to exec SUID/SGID applications, eliminates this big security hole.
People like to say that chroot prevents attackers from running anything within the chroot, but it really doesn't... No doubt the exploit code used to break-in directly overwrites locations in memory. A similar method can be used to run any code you wish, no matter what is or isn't available inside the chroot. It certainly won't stop someone from exploiting kernel bugs, generating/reading network traffic, etc.
Of course, these are the same types of people that think their systems are safer for having removed the compilers, and other (non-SUID/SGID) binaries that harmlessly occupy HDD space.
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
man chroot : /bin/sh).
[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:
AUTHOR
Written by Roland McGrath.
[/code]
Well.. the manual sums it all up.
Read and Comment at my BLOG
!!!
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.
The comment was directed at system administrators, not desktop users. You're safe :)
Basically chroot was an early attempt at virtualization. It allowed one to keep servers separated and contained, which improved reliability and availability. It has a minor positive effect on security, but not really all that much. There is a good argument to be made for not using chroot since it increases the maintenance effort, which frequently results in chrooted servers being neglected which reduces security. As for myself, I avoid using it, due to the maintenance issues.
Excuse me, but please get off my Pennisetum Clandestinum, eh!
Thanks, as this was not explicitly said, I am confuzzed. It happens waaayyy too easily, I must say.
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.
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...
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
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.
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.
> A process running as a regular user can break out too.
Only if it can get access to a broken SUID program, etc. I always though the point of a chroot in a security context was that the chroot only had the absolute minimum environment the task being isolated had to have, thus there shouldn't be too much in there to worry about getting exploited. Which is very useful.
Of course there are lots of uses for chroot that have nothing to do with security. Like keeping a whole 32bit environment seperate from the main 64bit install, wonderful tools like mock which allow keeping multiple distros on multiple arches installed and usable for building packages, etc.
Democrat delenda est
I agree that you shouldn't be running something like an MTA at a root level but like the above said, not every daemon has an option of being run at a lower level.
Sure its not good practice but if you need something working now you are not going to wait for the developers to change the code: especially if they have no intention on doing so.
Developers of many high level process I think have relied on chroot as a crutch, its more than just "up to the administrator" its more so up to the dev's to give you the option of not having to run the process as root in the first place.
Make SELinux enforcing again!
who don't even want to think about security. I've got a coworker who detests Ubuntu and swears he'll never use it because he doesn't want to use sudo all the time (i.e. the distribution doesn't have an administrator user by default apparently).
1. making a compact flash bootable.
2. see 1.
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?
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: There are actually a few places online that offer free shell access. That is, you can actually ssh in and get a commandline on a Linux box. I'm assuming they have decent protection.
I believe FTP does encrypted authentication, and it may even be possible to run the entire session over SSL. I'm not sure how secure this is.
Speaking of SSL, another possibility is WebDAV. Linux has a driver, I believe (probably FUSE), and there's probably client software for others. Basically, strip out any http urls and replace with https. Bonus over ssh is, your public key is signed by a source they probably already trust -- but if you don't want to pay for that service, you can always self-sign.
Next on the list, and this is a big one: VPN. There are all kinds of ways to do this -- my favorite is OpenVPN. You can prevent client-to-client connections, and use any server-side firewall to deny them access to the rest of the network. The only trick is, you have to either guess a very unlikely-to-be-used private network (something like 10.0.1.0, maybe), or you would have to provide more than one instance of OpenVPN, on different private subnets. But it wouldn't be automatic -- they would have to select VPN A or VPN B.
Either way, once you have that VPN connection, you can use pretty much any old insecure protocol. Straight FTP, Samba, NFS, or all of the above. All you need is plain old password authentication, or even IP-based authentication (NFS), given OpenVPN allows you to guarantee that a given IP is only owned by / routable to a given client (with a given key).
And finally, you could always do some sort of secure system (GPG, encfs, TrueCrypt, etc) on top of an insecure system. Some lamer could always intercept your traffic and corrupt your files, but you'd know about it. However, this would force you to write software if you wanted to protect the system from abuse, and not just the data.
Don't thank God, thank a doctor!
Go ahead. One of the (many) differences between Vista and Linux is that if you want to, you can march up to any of the core Linux kernel architects and tell them they have some fundamental long-standing unix interface totally wrong. The flip side of that is that they also won't stop anyone from flaming you if you do that.
And that's exactly what happened here. This guy wasn't posting a question on a local LUG. He was posting to the Linux kernel mailing list--the place where people actually meet to do kernel development. And he wasn't asking a question, he was arguing with people like Al Viro, a primary architect of the Linux filesystem api's. Which would be great if he was correct. But in fact he was totally wrong. And even that would be OK if he took the time to do his homework and to listen carefully when people explained the issue to him.
But he didn't really, so as a result he got a few flames. Some of the posters to lkml aren't polite in such a situation. I think that's kind of understandable, though actually agree that that's a problem. Are the core Vista kernel developers any better? Who knows? Does the general public doesn't have the option of participating in their development forums?
"You think Windows is better, just because there isn't a public record of every chair Microsoft's heads throw at their employees?"
Fixed that for you.
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
http://blogs.sun.com/chrisg/tags/chroot
Dr. Marshall Kirk Mckusick, private communication: ``According to the SCCS logs, the chroot call was added by Bill Joy on March 18, 1982 approximately 1.5 years before 4.2BSD was released. That was well before we had ftp servers of any sort (ftp did not show up in the source tree until January 1983). My best guess as to its purpose was to allow Bill to chroot into theThe truth of the matter, of course, is a) chroot is used as a security tool, whether misguidedly or not, b) superuser can break out of chroot, anyone who thinks otherwise is misguided or misinformed, c) when used in the sequence
- bind to a privileged port
- chroot
- drop superuser privileges
- interact with untrusted entities via protocol X (where X could be HTTP, DNS, whatever)
the unprivileged chroot containment has proven to be quite useful and practical as a security tool. Short of administrator incompetence (e.g. leaving naughty device nodes laying around in the chroot area) or clearly-admitted kernel bugs (e.g. http://secunia.com/advisories/15339/ from our favorite OS vendor), I'm not sure that anyone has ever "cracked" this set of precautions.I believe you still can't chroot out without being root.
Thus, the only point of jail is if you are either running an app as root, or you are putting setuid binaries in the chroot (and you don't trust those setuid binaries to be secure).
We also have selinux, which is a much better solution overall, if a bit overly complex. (For example, does jail prevent that root process from being able to grab privileged ports?)
Don't thank God, thank a doctor!
Not to be rude, but I found a chroot'ed SSH HOWTO in 3 seconds by googling 'ssh chroot'.
I'm not the type of person to actually come out and call someone an idiot, in so many words. So I'll just leave it at that.
They don't grade fathers, but if your daughter's a stripper, you fucked up. --Chris Rock
of using chroot is/was to isolate compromised processes. It would be pretty pointless to chroot a process that you knew for a fact could never run as root; you could just use ordinary permissions for such a process. You only do it if you fear an attacker could compromise the process and somehow obtain root privileges. If chroot were foolproof, such an attack would be emasculated. If root privileges allow a process to escape the chroot, then it is ineffective. Pretty simple.
why?
I've wondered about this myself, but ages ago. Since then I've found that in my particular situation it's not needed (VPN/SSH/WEBDAV). But a quick check on Freshmeat shows at least 2 possibilities: scponly, rssh.
I get that using a wrapper program like either of these is kind of cockeyed, but SFTP *is* the most commonly supported secure transfer protocol (webdav/ssh, but not nearly as drop-in for Dreamweaver users, etc).
Anyway, I think it's safe to say the *nix community is now big enough that most itches have at least been attempted to scratch. And FTR, there are assholes in every community, sounds like you just had a spot of bad luck.
Quack, quack.
Does Jailkit eliminate all of these problems of chroot?
Not incompetent. You can't blame admins who haven't been instructed properly, but you can certainly blame kernel developers who haven't clearly communicated what their tools are to be used for. Adrian ought to spend his time educating not insulting.
I'm rather weary of the "I have a bigger pen^H^H^H brain than you do" bullshit that goes on in IT.
Camping on quad since 1996.
You can do application isolation in one of four ways. The lighter-weight of the three require installing kernel patches and/or additional management tools but are not particularly invasive.
Linux VServer is the closest to FreeBSD jails; it uses a few kernel patches to add isolation contexts to processes and views of network interfaces. Unlike jail(8) you need to start a new init(8) in each context. But like jail all processes share the original scheduler and VM, and use the host system's filesystem natively, only chroot'd.
Another more comprehensive solution is OpenVZ. This is OS-level virtualization that is similar to Solaris Zones. It requires more extensive kernel patches and provisioning tools. It is designed primarily for dedicated server hosting scenarios.
Then there is UML (User Mode Linux). This is linux on linux emulation that runs a special version of the kernel as a userspace process. You give the UML guest a file which behaves like a hard disk from the perspective of that guest, or you can choose to use a special filesystem driver that uses a "real" directory up on the host. This is close to VMWare or Xen-like solutions except it can't run an unmodified OS, only one given a special UML kernel which doesn't really have hardware drivers -- it shunts the actual work in syscalls up to the host OS.
Finally there is KVM, which is included in the Linux kernel as of recently without patches. This is a lightweight hardware-assisted virtualization solution in the style of Xen that can run unmodified guest operating systems.
I hope this helps.
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
Of course now that I'd done the simple search I find it coincidentally, everywhere.
Quack, quack.
As to the discussion - nerds generally have low self-esteem and poor social skills. It's makes them friggin' fabulous to communicate with. :/
Good luck. I suspect you've already solved the problem above anyway.
I don't think you were in fact at the receiving end of his scorn. chroot is only something you would worry about on a large scale multiuser system, so it was directed to those whose job in part is to secure large systems. It's one of those things with kernel developers chatting on open mailing lists, it's easy to be taken out of context. In this regard, chroot has no problems - to break out you need superuser access, and by then it's too late. Simply put, it's something you would never have to worry about.
2. While operating a motor vehicle.
3. While dining at an expensive restaurant.
4. While dancing.
5. While urinating.
6. While defending yourself against a murder charge.
7. While picking fleas off a gorilla's back.
8. While seasoning a fine hamburger patty.
9. While being arrested.
10. While having sex.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
On the other hand, you aren't trying to post a fix to a part of the OS that relies on knowledge you don't appear to have.
My guess is that its okay to be ignorant of the internals of the OS and system commands, just as long as you don't go trying to tell other people how they are supposed to work. I think that's probably fair.
Marcus Ranum: 1997 Read what he says about chroot(). http://209.85.165.104/search?q=cache:x7STuouYe7oJ:www.ranum.com/security/computer_security/archives/security-for-developers.pdf+chroot+site:ranum.com&hl=en&ct=clnk&cd=3&gl=us
Then all hail the Paladin of security. http://www.ranum.com/stock_content/p-n-mjr-2-large.jpg
If the best you can come up with is "but they probably do it too" then you really ought to either think harder or give up on the reply. Just friendly advice, take it as you wish.
Slashdot - where whining about luck is the new way to make the world you want.
To clarify, the thing that's unique about /tmp is the last step of your trick. You can't delete the file in /tmp after creating it, because only the owner of a file can delete a file in /tmp.
More information
The owner is set to root since the owner and permissions are determined by the underlying entry in the file system called an inode. In your example, /tmp/bash and /bin/bash are just file names that point to the same inode. This means the new link, /tmp/bash, gets the same permissions as the original link, /bin/bash, and changing the permissions on one changes the permissions on both.
More information
It is my understanding that chroot _can_ be an effective security tool. It just has its limitations. One such limitation is that processes run as root can break out of the "chroot jail" (why is this, by the way?). Another limitation is that you have to be root to use chroot (and why is this?).
I wrote a little program called chrootexec which allows you to run commands in chroot jails as a normal user, circumventing both these limitations. To do this, it must have the capability to do chroot, setuid to the real user id, and setgid to the real user id; this can be accomplished by installing it suid root.
Please correct me if I got my facts wrong.
incompetent people running the government are a real problem
I thought it was called democracy.
A window lock will never keep out a thief. But it will make them go elsewhere, or decide it's not worth it. ... and every little helps!
If you're root you have a master key, so the lock has no meaning. But if you've not got your key yet it makes your attack a lot more obvious.
Without the lock the thief can make a tiny hole in the window and flip open the latch; once they're in they close the window and nobody can see the difference. With the lock the thief has no option but to smash the window, leaving lots of evidence that something is wrong. Likewise a computer attacker has to make themselves a lot more obvious if they want to get out of a chroot. They also have to know if another process will respond badly to a signal or if there's some IPC they can interfere with or a process they can attach with ptrace() or a local root exploit. They might have to wait around for the oppotunity to get to root or out of the chroot while all the time the logs build up.
So a chroot will discourage an attacker, just like window locks discourage a thief but they are not a security device because they don't actually add security they just strengthen the existing security a little
Disclaimer: I happen to know Alan and he's a bright chap. You shouldn't blindly believe everything bright people tell you but that doesn't mean they're always talking rubbish either.
I'm going to just chime in and say RAID (as most people use the phrase) is not a backup. Again - RAID (as most people use the phrase) is NOT a backup. As you suggested RAID (I assuming you are discounting "RAID0" as I don't think it helps your argument) helps safety - but only a particular type of safety. If you delete a file on most RAID systems the file is "deleted" from all the disks. The RAID did what you told it - it only distributed the data you told it to keep but sometimes mistakes happen and we would like to recover from them with minimal cost. Many people are told about RAID and conclude that it solves all possible data issues but it isn't that simple.
Additionally I have first hand experience of seeing hardware RAID5 fail due to a failing disk. It really does happen but at the moment it doesn't happen often and I was able to go back to backups. All I can say is - it is important to understand the scope and limitations of whatever system you are putting in place. A lack understanding on a given topic can really come back and hurt you. My understanding must be complete if I always want the correct answer and in those cases where it is not, just because I believe something to be true it need not be true (or even possible).
Finally I've been told that many locks you get today can be picked by a good lockpicker with decent tools in a relatively low amount of time. Further if someone REALLY wants to break into your house maybe they won't try and break the lock on the door but they will instead just smash a window round the back. I think there's a phrase "Locks only keep honest people honest" - they are only there to stop people casually getting into your house, not keep out the determined.
chroot is very useful when you're running software version N and you want to change into version N+1: you install the N+1 version on a partition and you use chroot so that the N+1 version believes it is alone.
/mount_point' this way by default the N+1 version doesn't see the chroot and the migration scripts can work without problem.
The issue is for migration: when you want to migrate some data from N to N+1, it is useful in the N+1 version to escape the chroot to access the N version and chroot makes it too difficult currently, I'd like to have a 'mount -chroot
Hmmm, make that 'incompetent people maintaining bridges are a real problem'.
molmod.com - computing tips from a molecular modeling
The superuser can escape from a chroot jail by doing "mkdir foo; chroot foo; cd .."
It could be because I went out drinking last night, but I don't really understand how that line of code would break out of a chroot.... Can anyone shed some light into my gin-induced fog?
Buses stop at a bus station
Trains stop at a train station
On my desk there's a workstation....
It's nice to hear that you're putting into practice security policies based on information you're getting from Wikipedia.
my password really is 'stinkypants'
You are "more right" than him, but you are wrong.
/dir1/file1 /dir2/file2" _doesn't_ create any kind of inode at all. It causes the system go to "/dir1/" and find the inode number in the directory entry that contains the text "file1" and then uses that number to create an entry in the relevant directory (/dir2/) that contains the new name "file2" and the previously mentioned inode number (and it "coincidentally" increases the reference count in the inode so the file system knows that the inode previously referenced by the name /dir1/file1 now has two names. NOTE that the inode doesn't know it's "name" or "names" which is why, if you trash your file system and then do an integrity check, the system will reattach lost inodes in lost+found (in ext2/3/4 and similar file systems) and only give them a number (the inode's actual number) as the "file name".
/dir1/file1 /dir2/file2" you are making a symbolic link. In _this_ case you make a new inode which references (typically) one single data block that contains the string "/dir1/file1" and the number of that new inode is put in a directory slot within /dir2/ tagged by the string "file2" so when the os comes by, and you open/cd/whatever that file /dir2/file2, the request becomes a name lookup of text "/dir1/file1". This leads to the various symlink shenanigans, particularly with chroot and friends.
"ln
It would be _DISASTEROUS_ to create a second inode who's data pointers pointed to the same data blocks as another inode. Among other things, you could _never_ know when a particular data block was finially deleted. Another problem is that the two inodes could end up owned by different accounts and possess contradictory times, permissions, and sizes. Dang disastrous.
BUT... if you "ln -s
STILL, a _hard_ link (the first example) just adds a name and number pair to a directory that is a _hard_ alias to the original file, and the _soft_ link is a reference by name.
Consider:
echo "First Name" > file1
ln file1 file2
ln -s file1 file3
rm file1
echo "Second Name" > file1
"cat file1" produces "Second Name"
"cat file2" produces "First Name"
"cat file3" produces "Second Name"
When you understand why, and you understand that the above exercise has involved 3 inodes (four if you count the current directory), but that the third (fourth if you count the current directory) inode doesn't come into use/existence until the second echo.... then and only then grasshopper should you again correct someone's understanding of inodes in a public forum.
8-)
ASIDE: words like "create" and "come into existence" are used here in the vernacular, for simplicity. In fact, for most current file systems, the inodes are created when the file system is created on the disk, and are allocated from and returned to the free inode pool(s) as opposed to being "created" or "destroyed" but that is a separate conversation...
Innocent people shouldn't be forced to pay for inferior software development.
--"Code Complete" Microsoft Press
Use FTP over SSL, not the same as SFTP, it usese plain old FTP over an SSL connection (same way HTTPS is HTTP over an SSL connection). I can think of a bunch of different reasons why you would want to do that. We do it because we have users who need to transfer moderately sensitive data, they're trusted not to be malicious but also trusted to get confused by weird sounding directory names like 'usr' and 'etc' and 'bin'.
If you don't want to use SSL, you could use FTP over an SSH tunnel, which would probably be a little trickier to implement (don't know of any FTP clients off the top of my head which can do this).
Man, if I'd seen that forum post I'd of ripped those guys apart - but that's because I'm a prick, just like them.
Like Penn would phrase it: "And then there's this asshole..."
umm...yeah, it's much better to do what they do in the Windows world, were they ignore the fact that users are doing the wrong thing and instead of pointing that out and teaching them developers make hacks to work around the users incompetence. eg. personal firewalls, anti-virus, anti-malware, preventing administrators from deleting specific files that the system thinks shouldn't be modified.
...and that is all I have to say about that.
http://jessta.id.au
I wouldn't ever do it -- while using Linux or Windows or OS/9 or even Multics, for that matter.
Actually Bill Joy got it from AT&T.
My November 1979 edition of the CB/UNIX 2.3 manual pages has a chroot(1) and chroot(2) man page. It probably was not a CB add on and instead came from AT&T.
Here's the entire desccription of chroot(2)
NAME
chroot - change root directory
SYNOPSIS
chroot (rootname)
DESCRIPTION
Rootname is the address of the pathname of a directoyr, terminated by a null byte. Chroot
causes this directory to become the process root directory. This smeans that any references to
filename beginning with slash are not relative to the real root of the UNIX file system, but
relative to the new root directory specified in this system call. The current working directory
remains unchanged. Notice, however, that a chdir to slash ("/") following the chroot system
call wiill change the working directory to the new root directory. Arguments to chroot are always
absolute: no special meaning is given to initial slashes even if a chroot is currently in effect.
This system call is restricted to the super-user.
SEE ALSO
chroot(1)
DIAGNOSTICS
The error bit (c-bit) is set if the given name is not that of a directory or that is not searchable
(executable) or the current user is not the super user. From C, a -1 returned value indicates an
error, 0 indicates success
ASSEMBLER
(chroot = 61)
sys chroot; dirname
====
One of the things we used to chroot for was in support of buildiing many releases of our products, chroot pointed the compiler to the right set of files.
Because you read a comment and automatically thought is was about YOU YOU YOU ...duck and cover
And apparmour is being included by default in ubuntu, which speaks volumes about the knowledge of their security team.
sudo is a pain and has itself seen it's fair share of security holes. Unknowledgeable users being discouraged from logging in as (or su to) root is a good thing but the "all shalt disable root logins and use sudo" mindset is silly. You can't say that someone who doesn't care for sudo doesn't care about security. I know every SUID/SGID executable on my servers and sudo isn't one of them!
So don't use seteuid--use setuid (without the "e"); this is what the article that you just cited indicates:
-rozzin.
I see where he's coming from. A lot of non-Linux users see Linux users as egotistical elitists who view the technical "normies" out there as incompetence, and I don't blame them. A good chunk of Linux users act as if they're god's gift to IT. The last place I worked at was full of people like this, and let me tell you how excited they made non-Linux users out there about trying out Linux. You can be a knowledgeable Linux user without being a douche about it....I am.
After reading that thread it sounds like at least half of the 'kernel hackers' are self-absorbed jerks that are incapable of communicating with other human beings except to say, 'I'm better than you.' It definitely turns me off to contributing code to the kernel, I guess I'll have to find a friendlier open source project to work on. Shouldn't we encourage people to contribute to the community instead of showing them what huge idiots they are and telling them to crawl back into whatever hole they came from because we are perfectly capable of writing an operating system without them?
'Go try them, then come back and admit your error,' congratulations Alan Cox, you're an asshole!
As for the parent, the post you responded to is right. Not everyone can be a genius, and calling someone incompetent because it makes him feel better about the fact that no one likes him in real life isn't particularly constructive behavior. Who cares if the comment was directed at that guy or not, it's still a stupid thing to say. All he's doing is provoking people so he can 'burn' them even more. Welcome to Flaming 101.
What about buffer overflow privelege escalations? If an app is vulnerable to this, can't it (or rather, the code it can then use/run) potentially escalate the user entity it runs under/as, is it not possible to 'break out' of a chroot jail??
sudo adduser --uid 0 --gid 0 myveryownroot
Problem solved for your coworker.
Of course Ubuntu has a root user. There's just no valid password for it. So you can't log in or su to root. You can 'sudo su' and get a root shell. It's really no different. Sure you have to type 4 more characters, but you have to remember one less password. Big deal.
Give me Classic Slashdot or give me death!
If you read the ubuntu specific docs, it would tell you to enable the root account by running sudo passwd root.
I said no... but I missed and it came out yes.
So are the same idiots claiming chroot is security the same people who have been puling for decades that Microsoft's security was supposedly "broken" for now emulating teh Lunix's chroot-based "security model"?
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.
You can do that to the Vista kernel architect, too. In either case they're not going to do anything about it.
So true, chroot was never designed for security, neither was the internet.
Lets stop using them both.
In this case, a technical "normie" is incompetent.
The word incompetent is not necessarily an insult. You can call me an incompetent surgeon, bridge designer, president or security solution designer, and I won't take offence.
It is simply an (accurate) description of my lack of competence in these areas.
May we live long and die out
Feh, not everyone gets to be a rocket scientist. Does that mean that rocket scientists should listen to every burger flipper that wants to "contribute to rocket science?".
Not everyone CAN contribute to "the community" that is the linux kernel. This is a bit different level of software engineering that your typical program. I realize you were probably brought up by the feel-good "everyone can reach for the stars" american educational system, but that's not how the world works. Do you seriously think you can contribute to a project JUST BECAUSE YOU THINK SO? No. You can't. Either because it's not your specialization, or because you don't have the talent or inherited traits for it. I thought it was obvious. You think you can play at the same level of the NHL or NBA just because you think you can or want to? Don't kid yourself.
And additionally, the person complaining about chroot had an attitude. He was put back into place.
Here is another POV - the person thought he had the shots to go and bother busy individuals who are experts in their field, complaining to them about THEM misunderstanding something. This is equivalent to some country rube bitching to rocket scientist about the space ship looking not the way he imagined... Why should your voice be heard? Why should anyone care? Why should Alan Cox care? Respect is earned, and guy with the rant to Alan Cox didn't earn it by behaviour, nor by having done something of value...
Take advantage of the chroot ability in vsftpd and try to break out of that one using an FTP client. It must be impossible. Which is good, because I'd hate to have users inadvertently find their way into other system directories (even if they do lack write privileges).
/* No Comment */
A good example of that is presidential security.... How many millions (billions?) of dollars have gone into presidential security, yet attackers with minimum resources were still able to get through to Ronald Regan and Jimmy Carter.
That it's enough deterrent to deter most sane attackers is proven by the fact that nobody has had serious success in attacking George Bush Jr.
____
Chroot certainly doesn't, inherently, hurt security (except to the extent to which it gives some users a false sense of security). It does, however, provide an extra barrier to hackers who might trick (for example) FTP into doing something stupid -- they then need to do even more work to do damage outside of the processes' chroot jail.
It may not be foolproof, but it can provide enough of a barrier to cause an attacker to go find an easier target (which is, again, the real purpose of security).
Using chroot to contain root users, on the other hand is like having a maximum security prison with really secure doors -- remotely controlled with intelligent cameras, etc.... and an emergency key under every mat. As was mentioned by Cox: there are just so many holes in tha model that it's better to educate users about the impropriety than to try and fix what is an inherently broken process.
OS Software is like love: The best way to make it grow is to give it away.
Do this Google search and see if it's any help.
/. tradition I haven't read his posts yet). You'll then need to patch the SFTP subsystem to provide the chroot function and rebuild it.
You'll need a privilege-separated sshd (such as OpenSSH versions 3+) because chrooting daemons that run with high levels of access provides little or no security (which, I suspect, is the point Alan was making, but in grand
With a privsep'd sshd, a process with the uid/gid of the authenticated user will be spawned once authentication completes. Obviously, during authentication elevated access is required (though not necessarily root superuser) so that authentication data (LDAP, passwd file, shadow suite, NIS, whatever floats your boat) can be accessed for validating the password, but the communication stream from the user can be handed off to a less privileged process before anything other than user/password is processed. SSH isn't like telnet, you have to authenticate before you can get a real interactive session.
I'm not going to pretend this isn't hard. You should consider yourself pretty competent if you can whip up a chrooted sftp in less than a few hours. If you can do that and you also understand all the security implications without having to extensively study the mechanisms of SSH authentication, your chosen OS's chroot() implementation, and your specific application and user needs, you are a veteran security expert. If your system can be used in ways that would cause someone to be jailed or killed, you should have a veteran security expert on your staff.
The first major distribution to ship a chrootable SFTP with a priv-sep sshd will gain quite a bit of marketshare from HIPAA, SOX, and FDA regulated industries. There are costs associated with having to maintain your own packages outside distribution channels that corporations and hospitals would like to avoid.
Eh, lunch break's over. Good luck!
I'm going to try my best to explain; please forgive whichever parts are redundant for you.
--- SFTP
As I'm pretty sure you know, there already is a protocol - SFTP - that connects via the SSH daemon on most any Linux box, and provides secure, FTP-like file transfers supported by most (but not all) FTP clients. Plus it doesn't have all the multi-port trouble with firewalls that FTP sometimes does.
Overall, I think SFTP DOES what you're mainly looking for, and I'll explain a bit more below.
--- Userbases
It's not impossible, but is annoying, to have one Linux OS image super-securely managing two different SETS of users who have totally different profiles of what they're allowed to do and what files are relevant to them. For example, if you have a mailserver and a webserver with totally different userbases, you really want two Virtual Private Servers and therefore two different root accounts so even a root escalation on one server won't compromise the stuff on the other. Of course, this is not necessarily relevant if you're mostly giving webspace and mail to the same set of users.
--- fake security is really bad
What you really, REALLY don't want is what chroot generally provides - a facility where the admin FEELS like it's safe but really it's not.
--- Real User Accounts
ssh as a nonroot user into a server, then type:
ps -elf | grep ssh
You'll note that you connected to an ssh daemon which then, immediately, downgraded part of itself to run as your non-root user. This is really important - after the initial, hopefully minimal connection, everything you do is as your user. So it's totally constrained by all the things in the OS that constrain that user.
This is superior because:
You can only do the same stuff your user SHOULD be able to do.
No bug in the main part of ssh can let you perform an action with higher/wrong permissions than that - because it can't give you MORE permission than it has itself.
No bug in the child part of ssh can let you escalate privileges up to root, because IT can't do that.
No administrator has to know a "special way" to disable a user - if the user's account is disabled OR they don't have access to a file, they can't get to it.
I think there are other reasons along these lines, but I'll conclude this section with saying "real user accounts are usually A Good Thing (tm)"
--- Setting up chroot isn't much easier than setting up a VPS
If you take to heart the user account thing, then you don't want a "fake" jail that only works for the FTP-like access; you want a jail that jails the whole FTP-like PROCESS, too, in case there turns out to be an exploit in it.
However, you then need to personally make sure the jailed FTP-like process also has access to anything it might need. Like "ls", and who knows what else.
The general case of this is to setup an entire virtual linux installation for them inside chroot and then rip out what functionality you don't want them to have, which is a lot of work.
Because of how chroot is designed, this also just isn't secure, but it's not a trivial piece of software to totally jail a process, and it's not cheap to do so. You have to make lots of things secure in an way that's entirely unlike other stuff in Linux.
At the core, this process still has permission to do whatever your user has permission to do in Linux. AND, if your user has too much control they're going to be able to do Bad Things even in a chroot jail.
But you could go a step further and setup a virtual private server - like Xen, User Mode Linux, OpenVZ or VMWare. This guarantees (to the limit of the security of the virtualization software!) that not only are the files protected but the process is totally contained in it's own space and can't "escape" to the root OS. Essentially this IS the software you're looking for; it totally jails processes.
Certainly, while there's really no cheap way to totally isolate a process, there could be a way in Linux more
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Well, if the country in which you abide purports to be a democracy, then you have a stake in ensuring that incompetent people don't run the government.
A chroot on Unix operating systems is an operation that changes the root directory. It affects only the current process and its children. "chroot" itself can refer to the chroot(2) system call or the chroot(8) wrapper program. The "chroot" system call was invented during development of Version 7 Unix, in order to provide a realistic test environment of the distribution being prepared. A program that is re-rooted to another directory cannot name files outside that directory. 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. In practice, chrooting is complicated by programs expecting at startup to find scratch space, configuration files, device nodes and shared libraries at certain preset locations. To allow programs to spawn inside the chroot directory, it must be populated with a minimum set of these files. Programs are allowed to carry open file descriptors (for files, pipelines and network connections) into the chroot, which can simplify jail design by making it unnecessary to leave working files inside the chroot directory. This also works as a simple capability system, in which the program is explicitly granted access to resources outside the chroot based on the descriptors it can carry in.
A chroot is actually can be use as isolation, recovery, privilege separation, and honeypotting. 1) Isolation A chroot environment can be used to create and host a separate copy of the operating system. Testing and development A test environment can be set up in the chroot for software that would otherwise be too risky to deploy on a production system. Dependency control Software can be developed, built and tested in a chroot populated only with its expected dependencies. This can prevent some kinds of linkage skew that can result from developers building projects with different sets of program libraries installed. Compatibility Legacy software or software using a different ABI must sometimes be run in a chroot because their supporting libraries or data files may otherwise clash in name or linkage with those of the host system. 2) Recovery Should a system be rendered unbootable, a chroot can be used to move back into the damaged environment after bootstrapping from an alternate root file system (such as from installation media) 3) Privilege separation Chroots are often used as a pre-emptive way of containing a security breach by preventing an unprivileged attacker from doing any damage or probing the host system with a compromised program. An attacker with root privileges, however, may trivially defeat this separation because the chroot does not bar system calls, shield processes outside the chroot from tracing or disallow access to block devices. 4) Honeypotting In a version of the above, a chroot directory can be populated so as to simulate a real system running network services. However, unlike an actual jail mechanism, chroot does not virtualize system calls, access to block devices or virtual file systems (such as /proc and /sys on Linux). This may make it difficult to conceal the presence of the system outside the chroot.
I've seen the chroot utility for decades; I generally thought it to be a good idea for those working in really hardened environments, though I've not used it myself, since I don't have a solid understanding of it. (Avoiding what he talks about).
But maybe this would be a good time to start using the virtualization tools that come with Linux; Xen and the like. Maybe it's time we (strategically) replace chroot with virtualization? It would seem easy to 'flush and fill' the guest machine if it ever gets hacked, and it'd seem pretty tough to 'get outside' of it, aye?
--- For a good time mail uce@ftc.gov
wow.. Using a chroot actually a good action to improve internet security and this should be continued
Microsoft has never emulated chroot in Windows. Windows uses things like tokens and ACLs and policies to secure resources.
I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
Lincoln Stein, the author of CGI.pm and GD.pm and a few books, and the co-author of the WWW Security FAQs, wrote a tool called sbox that is used for securely running untrusted CGI scripts. And sbox does use the chroot() system call (in addition to other security measures) to confine the process to the CGI script owner's home directory.
Also, from the aforementioned FAQ: "You can't make your server completely safe, but you can increase its security significantly in a Unix environment by running it in a chroot environment."
So, the words, "chroot is not and never has been a security tool" are simply wrong. Unless you are willing to argue that Lincoln Stein belongs to "incompetent people implementing security solutions" and that W3C publishes bullshit on their web site.
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 have to understand the reality of that comment... The fact is, lots of people try to implement security solutions (or solutions of all sorts) without taking the time to really understand how they work, and the ramifications of using them. Often such people are inexperienced system administrators, or worse still they are people who are not system administrators at all, but nevertheless are tasked with maintaining some piece of infrastructure and keeping it secure. This is a fact of life, but such people rarely succeed in truly securing the infrastructure in question; they simply lack the knowledge and experience required. Due to other requirements being given to them, they simply lack the time to do the required investigation to understand the software enough to sufficiently provide the requisit level of security. Often enough, their efforts are sufficient, mainly because no one sufficiently competent at breaking into computers actually cares about getting into the resource in question. Nevertheless, a competent and determined attacker will succeed at bypassing their efforts to secure the resource. If you're such a person, you shouldn't take the comment above as a personal insult -- you're in a tough position. But instead, you might take away from such a comment that security is extremely complex, and a cursory knowledge of security probably just won't help you out all that much... If you are responsible for managing the security of, well, anything, then you need to completely understand the thing you're securing and the solution you're using to secure it. If you don't, you can't possibly know what holes you're leaving open, nor the potential impact of getting it wrong. Most people simply don't understand this aspect of security.
I wrote a piece of security software (which happens to make use of chroot to improve security), and I see this all the time. The e-mail thread that spawned this article is a prime example: people complain about a particular behavior being broken, but in actuality there's nothing wrong with the behavior; it's their own knowledge that is lacking.
I don't completely agree with Alan; chroot() can effectively be used as a security tool under specific circumstances. But this can only be true if (along with other limitations) the code running inside the jail is not running as root, and the essence of what he said is correct. Don't forget: root is essentially the god of his system; he can bypass file system permissions, alter running programs running in memory, and (if he's sufficiently clever) even change the way the kernel works at a whim; and yes, he can break out of a chroot jail, which is less drastic a change (or intrusion) than some of that other stuff. The root user can do anything, by design.
My software does the best it can to maintain security by calling a special SUID helper program to create the chroot jail, calling the chroot() system call as soon as it programmatically is able to do so, and immediately dropping root privileges after that. In such a way, chroot() can be an effective security tool. But it is NOT magic... you need to know what you're doing, and take great care to get it right. Certain types of misconfiguration of my software can easily result in a system that is easy to exploit. This is not a flaw in my software per se; it's just a fact of life. Most people -- even experienced programmers -- just don't have the required detailed knowledge that is needed to get it right. This doesn't make them bad people, and it doesn't even make them bad programmers. It simply makes them uninformed about a particular aspect of system behavior and programming. Any programmer, no matter how experienced, will have such gaps in knowledge. By definition, they are incompetent to program a solution which makes use of them. That statement isn't necessarily meant as an insult; it's just a fact.
chroot will only address the application using it while other vulnerabilities is remain, if the system is running unpatched. If a chrooted program has a file handle open before the chroot call is invoked, that file handle remains open across the chroot and could potentially become a gateway out of the sandbox. Of course, that presumes that a vulnerability exists that can exploit the file handle.
Well, if the country in which you abide purports to be a democracy, then you have a stake in ensuring that incompetent people don't run the government.
Fascist! Incompetent people deserver representation too. In my country they certainly are!
i rather have been use windows...