Chroot in OpenSSH 62
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!"
Re:Why bother? (Score:5, Informative)
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.
Re:Why bother? (Score:5, Informative)
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.
Re:Why bother? (Score:5, Informative)
I imagine something similar would be forthcoming regarding OpenSSH specifically.
Re:Why bother? (Score:4, Informative)
For regular user accounts, a properly configured chroot jail is still a very useful security tool.
Re:Why is this news? (Score:3, Informative)
Nothing New (Score:2, Informative)
FTP servers have been doing this for years (Score:4, Informative)
It's only natural that this same chroot feature would be added to sftp.
Re:Oh thank god (Score:3, Informative)
It will let you connect to sftp servers, and have a sane command line experience. It also has many nifty mirroring commands.
Re:Tell us more. (Score:3, Informative)
Step 1: Become root
Once you are root, there are dozens of ways to break out of a jail (all the way from modifying kernel memory structures directly to rewriting inodes to installing a kernel module that grants you access to whatever you need, etc...
Re:Tell us more. (Score:5, Informative)
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!
Re:Why bother? (Score:2, Informative)
The (now defunct) commercial SSH has had this feature for almost 10 years.
Re:Tell us more. (Score:3, Informative)
It's far worse, at least in the Linux kernel (and quite probably other Unix as well but I haven't studied them). The linux kernel assumes that the PWD is at or below the chroot. When a system call parses a pathname, it substitutes the chroot for a leading /, and when walking through a .. in a pathname, it checks that the current directory in the walk isn't already the chroot before following .. up.
So, once B gets to A's chroot (/home/sorta-trusted), it can access the real / as ../.. because now, the ..'s in the path won't pass through the stored chroot directory (/home/sorta-trusted/not-so-much. So, B diropens ../.. and passes that to A.
So, interestingly, A can grant B access to something it doesn't have itself. B can then return the favor. Many argue that chroot isn't a security measure in the first place, so it's firmly WONT FIX.
Personally, I say it IS a bug since right or wrong, it is used as a security measure all the time (and is quite a useful one but for the holes). I'm testing a patch that closes the escape even for root now (unless root hacks around in the kernel's memory of course but that can also be closed in a capabilities system).