Slashdot Mirror
Chroot in OpenSSH
bsdphx writes "OpenSSH developers Damien Miller and Markus Friedl have recently added a nifty feature to make life easier for admins. Now you can easily lock an SSH session into a chroot directory, restrict them to a built-in sftp server and apply these settings per user. And it's dead simple to do. If you need to allow semi-trusted people on your computers, then you want this bad!"
Giving someone a shell and putting them in a chroot crafted to look and function like a full system is one thing.
Giving someone an SFTP session and chrooting them into a subdirectory is another thing.
The feature added in this commit was arguably intended for the latter purpose given the additional changes to the SFTP subsystem that were included. There are countless tutorials and patches and scripts that are available to achieve chrooted SFTP-only access, but now it's been implemented in the core of OpenSSH. In my eyes, this solution is not only a "cleaner" solution to the problem, but it's probably more secure too.
They are probably better than giving semi-trusted users full filesystem access, even if they aren't perfect security. It's not even that chroot is inherently broken, it's just that people were using it incorrectly (setting it suid or letting the user become root inside of their jail). Most of the complaints seem to be "the user managed to get root and broke out of the jail", which is a problem with whatever allowed your user to become root in the first place, not the jail itself.
Basically, to break out of a chroot you need to be root. If you're root, then you've already defeated the security on the box anyway. Don't let untrusted users become root.
I read the internet for the articles.
I imagine something similar would be forthcoming regarding OpenSSH specifically.
They're not secure for root users. That was the issue identified in the recent "read" you mention--someone was pointing out that root can break out in a particular way, and the kernel devs responded that 1) that was by design, and 2) locking that down left an infinite number of other ways to break out if you're root.
For regular user accounts, a properly configured chroot jail is still a very useful security tool.
Anyone who loves or hates any language, platform, or manufacturer, doesn't know what they're talking about.
The purpose of this feature doesn't seem to be to restrict what a shell user can do. Rather, if I read this correctly, it restricts what files a user can access via sftp. Without this feature, a user can sftp in, and then cd to / or any other folder that he has rights too. This chroot feature lets the admin limit the root to, say, his home directory, or some other folder such as a virtual web root or something.
It's only natural that this same chroot feature would be added to sftp.
In the right circumstances, 2 non-root users can conspire to break out of jail if one is chrooted below the other.
Let's say A is chrooted to /home/sorta-trusted and B to /home/sorta-trusted/not-so-much.
A diropens his / and creates a unix socket in /not-so-much. B opens the socket in his /. Now, A passes his fd to his / to B. B then does fdchdir on the fd and he's out of jail. Now B can break A out.
The moral is, never use nested chroot jails!