Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Chroot in OpenSSH

ScuttleMonkey posted more than 5 years ago | from the making-life-easier-always-my-goal dept.

Security 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!"

cancel ×

62 comments

Sorry! There are no comments related to the filter you selected.

Why bother? (3, Insightful)

whoever57 (658626) | more than 5 years ago | (#22491700)

Didn't we just read that chroot "jails" are not secure?

Re:Why bother? (0, Insightful)

Anonymous Coward | more than 5 years ago | (#22491754)

When has that ever stopped the OpenBSD/OpenSSH developers? Security is what they say it is.

Re:Why bother? (5, Insightful)

bsdphx (987649) | more than 5 years ago | (#22491882)

Understanding the issues is better than parroting what you've heard from random sources. Given the OpenBSD and OpenSSH track record for security it's obvious they have some serious clues about security.

IMPORTANT MESSAGE FOR bsdphx!!!!! (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#22496382)

From the summary:

then you want this bad

"badly".

Re:IMPORTANT MESSAGE FOR bsdphx!!!!! (1)

khellendros1984 (792761) | more than 6 years ago | (#22500630)

I think English speakers are slowly dropping use of "ly" on the ends of adjectives. If so, it's one of those things that will slowly happen more and more, until that's just the way it's done.

Re:IMPORTANT MESSAGE FOR bsdphx!!!!! (1)

bytesex (112972) | more than 6 years ago | (#22500762)

'If so, it's one of those things that will slow happen more and more, until that's just the way it's done.'

Did that sound good to you ? (Ironically, the word 'good' should really have been 'well' in the previous sentence)

Re:IMPORTANT MESSAGE FOR bsdphx!!!!! (0)

Anonymous Coward | more than 6 years ago | (#22501620)

Did that sound good to you ? (Ironically, the word 'good' should really have been 'well' in the previous sentence)
Actually, good is the appropriate word, since you are asking whether the statement was a good, or proper, use of English. Otherwise you are asking whether or not the sounds of the words were successfully produced and transmitted.

Re:IMPORTANT MESSAGE FOR bsdphx!!!!! (1)

IpalindromeI (515070) | more than 6 years ago | (#22501704)

Ironically, the word 'good' should really have been 'well' in the previous sentence

Did it change the meaning to something other than what was intended? Because that's what ironic means.

Making the same mistake yourself while correcting someone else is not ironic. It's just humorously coincidental. Please watch this episode [wikipedia.org] of Futurama for further education.

Re:Why bother? (3, Interesting)

Wesley Felter (138342) | more than 5 years ago | (#22491884)

Didn't we just read that chroot "jails" are not secure?
I've read those arguments and find them confusing. Sure, root can break out of a chroot, but what about non-root users?

Re:Why bother? (1)

Brian Gordon (987471) | more than 5 years ago | (#22492810)

I don't really know anything about chroot security either, but the first thing that occurs to me is that there's way too much code running/setuid'd as root or in kernel/driver space to just change the filesystem interface and expect that to be secure. You can't possibly lock down every interface in all of this code without a more pervasive solution.. especially since we can barely (read: we can't) keep code listening on internet-accessable ports secure from buffer/integer overflows and other tricky business. How on earth are you going to lock down everything from cron to ls?

The idea (1)

warrax_666 (144623) | more than 5 years ago | (#22492978)

is that cron and ls aren't in the chrooted filesystem. That's why they're (supposedly) more secure than just running the daemons "from" /.

Re:The idea (0)

Anonymous Coward | more than 6 years ago | (#22500820)

Cron and ls aren't magic programs. Unless your program is SUID root, it's just making API calls to the kernel, calls ANY uploaded binary can make. Those are the bugs I worry about. So you have three solutions: trust the kernel will have no security bugs, try to prevent the user from running arbitrary code, or use something like SELinux that has more fine-grained access controls.

I like the last solution, as it doesn't seem like a quick patch job to symptoms, and actually addresses the all-or-nothing nature of security on Linux.

Re:Why bother? (5, Informative)

illegibledotorg (1123239) | more than 5 years ago | (#22491946)

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.

Re:Why bother? (1)

mike_sucks (55259) | more than 6 years ago | (#22498498)

"Giving someone an SFTP session and chrooting them into a subdirectory is another thing."

Yep, that's precisely why my ears perked up upon hearing this, for hosting providers that want to provide secure remote file access, this is awesome!

/Mike

Re:Why bother? (2, Informative)

schon (31600) | more than 6 years ago | (#22498662)

that's precisely why my ears perked up upon hearing this, for hosting providers that want to provide secure remote file access, this is awesome
My question is: what took so long?

The (now defunct) commercial SSH has had this feature for almost 10 years.

Re:Why bother? (1)

mike_sucks (55259) | more than 6 years ago | (#22499120)

Yeah, good question. I dunno - maybe everyone was standing around asking "when is someone going to do this?" and using FTP(S) in the mean time. I might have been. ;)

/mike

Re:Why bother? (4, Informative)

jandrese (485) | more than 5 years ago | (#22491960)

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.

Re:Why bother? (0)

Anonymous Coward | more than 5 years ago | (#22492236)

Sorry, you're wrong. There are methods of breaking out of a chroot that don't require root.

Tell us more. (1)

Valdrax (32670) | more than 5 years ago | (#22492354)

I'd like to hear more about methods of breaking out of a chroot jail without becoming root during the process.

Re:Tell us more. (2, Informative)

jandrese (485) | more than 5 years ago | (#22492844)

Yeah, every method I've seen starts with:

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. (0)

Anonymous Coward | more than 5 years ago | (#22495960)

Hey, it's me, your recent friend/fan who has been the victim of modstalking and whom for that reason you can only talk to discretely.

I told you I've been through vengeful moddings before, and I'd get through this one too. I was right -- check my history! Karma has been revived from terrible, back to positive, as of this moment. Not due to admin intervention, but due to me making enough good posts to get it back up. (Keep in mind that at the time I friended you, I had gone from excellent to terrible in under a week. Ouch!)

Hope to see more of your posts in the future. :-)

Re:Tell us more. (4, Informative)

sjames (1099) | more than 6 years ago | (#22497530)

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:Tell us more. (1)

Just Some Guy (3352) | more than 6 years ago | (#22510370)

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.

That's pretty interesting! In practice, though, what would that get them? B would now have access to A's chroot (possibly - file permissions might be too restrictive anyway). If A trusts B that much, they could just share A's login.

Not saying this isn't serious, but I'm too tired to think of a useful attack vector at this moment. Am I missing something?

Re:Tell us more. (2, Informative)

sjames (1099) | more than 6 years ago | (#22511690)

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

Re:Tell us more. (1)

Just Some Guy (3352) | more than 6 years ago | (#22514462)

You know, I've had two "oh crap!" moments involving computer security. The first happened when I learned about SQL injection. The second occurred just now when I read your letter. Thanks for the followup!

Re:Why bother? (0)

Anonymous Coward | more than 5 years ago | (#22492818)

So we are supposed to take it on the word of anonymous coward who says "is not".

How about giving examples or links. Otherwise, I don't believe you.

Where's the -1, Dumb Mod? (0)

Anonymous Coward | more than 5 years ago | (#22491966)

Insightful? Please.

Hooking up a computer to the Internet, by default, is completely insecure.

Yeah, why bother?

No security is foolproof; sure, chroots can be broken. They're also another obstacle in the way of your box being wtfpwned.

Re:Why bother? (4, Informative)

parcel (145162) | more than 5 years ago | (#22492130)

Didn't we just read that chroot "jails" are not secure?
You may want to take a look at http://www.openbsd.org/faq/faq10.html#httpdchroot [openbsd.org] , especially the section titled "Should I use the chroot feature?".

I imagine something similar would be forthcoming regarding OpenSSH specifically.

Re:Why bother? (3, Informative)

jjohnson (62583) | more than 5 years ago | (#22492178)

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.

Re:Why bother? (1)

ianezz (31449) | more than 5 years ago | (#22492284)

Didn't we just read that chroot "jails" are not secure?

Only when you have full shell access. This patch is just about confining sftp file transfers via chroot(2) for some users without the burden of setting up a full chrooted environment. Sounds really sweet.

FTP servers have been doing this for years (3, Informative)

caseih (160668) | more than 5 years ago | (#22492632)

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.

Re:Why bother? (1)

wolferz (1173471) | more than 5 years ago | (#22494192)

I have the same question... but for slightly different reasons. As I recall there was a huge fuss about the devs responsible for chroot implementation in bsd telling every one to get lost off when a built-in method for escaping a chroot jail was discovered. People wanted the "vulnerability" fixed and the devs responded with "it isn't a vulnerability, it is a feature... why are you using chroot for security any way?"

Long story short the devs made it clear they didn't give a crap if chroot jails could be broken out of, they never intended chroot to be used for security any way.

maybe i misunderstood though.

Re:Why bother? (1)

jjohnson (62583) | more than 6 years ago | (#22499594)

You misunderstood that the whole debate was about what a root user could do from within a chroot jail. A properly limited user account can be secured in a chroot jail (i.e., not simply chrooting but configuring a jailed environment).

The devs were correct that chroot alone was not designed for the purpose of security and can't be used alone to provide any.

No, I don't want it bad (0, Offtopic)

Anonymous Coward | more than 5 years ago | (#22491718)

I want it good. Perhaps you meant badly?

Bad to the bone (1, Funny)

Anonymous Coward | more than 5 years ago | (#22492134)

I want it good. Perhaps you meant badly?
Have you seen that new Ferrari? That's one bad piece of machinery!

(However, in this case you're correct in your usage.)
 

Re:Bad to the bone (1)

nuzak (959558) | more than 5 years ago | (#22492272)

I love the PowerGlove, it's so Bad!

Re:Bad to the bone (0)

Anonymous Coward | more than 5 years ago | (#22492398)

At least they didn't say "I want it sick!"

Damn kids...

Re:Bad to the bone (0)

Anonymous Coward | more than 5 years ago | (#22493588)

"I'm totally gay for chroot!"

Re:Bad to the bone (0)

Anonymous Coward | more than 5 years ago | (#22492428)

Have you seen that new Ferrari? That's one bad piece of machinery!

I don't like them either.

Oh thank god (2, Interesting)

Just Some Guy (3352) | more than 5 years ago | (#22492144)

Now I can finally switch some customers from FTP to SFTP. Thanks for making this hugely useful change!

Anyone know if SFTP logging will be added any time soon? That's the last missing feature i always have to manually patch in.

Re:Oh thank god (2, Insightful)

pembo13 (770295) | more than 5 years ago | (#22492448)

All we need now is some form of virtual user system that can be mapped to a real, unprivileged user, preferably with a flexible auth system.

Re:Oh thank god (1)

Just Some Guy (3352) | more than 5 years ago | (#22492970)

For real? My sarcasm meter is out of whack today so I can't tell.

Re:Oh thank god (1)

pembo13 (770295) | more than 5 years ago | (#22495632)

For real

Re:Oh thank god (1)

Just Some Guy (3352) | more than 5 years ago | (#22495758)

OK, just checking. It's been a long day. :-)

Anyway, would something like Kerberos fill the bill for you? I use it to navigate around our network, and it's not that hard to do once you get over the initial learning curve. If you're stucking working with Windows, you can even auth against an Active Directory domain.

Re:Oh thank god - vsftpd v sftpd vs. vs ftpd. (1)

anon mouse-cow-aard (443646) | more than 6 years ago | (#22496334)

I really love how vsftpd works.

This is a "Very Secure FTP Daemon" I would love for it to be configured exactly the same, but
the transport protocol would be Sech-file-xfer draft protocol (SFTP)

vssftpd ?

how about just a protocol option in the config of vsftpd...

Re:Oh thank god (1)

David_W (35680) | more than 5 years ago | (#22492488)

That's the last missing feature i always have to manually patch in.

I'm still hankering for tab completion in SFTP myself... maybe someday.

Re:Oh thank god (2, Informative)

PylonHead (61401) | more than 5 years ago | (#22492680)

Use lftp

It will let you connect to sftp servers, and have a sane command line experience. It also has many nifty mirroring commands.

Re:Oh thank god (0)

Anonymous Coward | more than 5 years ago | (#22494658)

Well, I'm not sure about logging, but you could always use scponly [sublimation.org] . I've got a friend who uses it on several servers and has been quite happy with it.

Why is this news? (1)

Abattoir (16282) | more than 5 years ago | (#22492432)

I was doing openssh(+sftp) with chroot on Solaris 2.6 several years ago. Does this have some Ubuntu GUI to make it easy or something?

Re:Why is this news? (2, Informative)

Doctor Crumb (737936) | more than 5 years ago | (#22492532)

This is news because the chroot and sftp server are now built in to the openssh binaries, so you don't have to manually set up the chroot. While there's no GUI, it is in fact now easier to set up such a thing.

Re:Why is this news? (1)

LurkerXXX (667952) | more than 6 years ago | (#22502100)

Ubuntu GUI? Where do you get Ubuntu from? This is from the folks who make OpenSSH. And OpenSSH is made by the OpenBSD folks, not Ubuntu.

This simply makes it much easier to do what many folks have been setting up manually for a long time. I'm hoping they'll follow it up with SCP support as well. Time to buy another CD set to support the project :)

Nothing New (2, Informative)

NYFreddie (84863) | more than 5 years ago | (#22492538)

This isn't really anything new. This functionality has existed as a patch for a while. It's still nice to see that it's finally being integrated into the main tree, though.

Does This Mean (2, Interesting)

ajs318 (655362) | more than 5 years ago | (#22492700)

Does this mean that I can give users shell access, by placing (hard links to) a stripped-down busybox and ash in $HOME/bin, and they won't be able to access anything outside the chroot environment? That could be sweet.

all that for sftp? (3, Interesting)

sgt scrub (869860) | more than 5 years ago | (#22492746)

It is cool tech but not the way I would do things. WebDav with ApacheSSL properly installed is lots safer. IMHO there should never be user accounts on a machine, other than root and the person administrating the box.

Re:all that for sftp? (3, Insightful)

evilviper (135110) | more than 5 years ago | (#22495562)

WebDav with ApacheSSL properly installed is lots safer.

Why? No privilege separation. A MUCH bigger code base.

Not to mention fewer standalone programs.

IMHO there should never be user accounts on a machine,

Why not? The user security model is reliable and time tested. It does not require reinventing the "user". It does not depend on one program handling it's own system of virtual permissions correctly. It does not depend on the security of a large program that users directly interact with.

I can see ample reasons sftp is safer.

Re:all that for sftp? (0)

Anonymous Coward | more than 6 years ago | (#22501324)

One advantage that I can see is that while one program needs to handle its own system of virtual permissions, those "user credentials" are valid nowhere else on the system. Someone attempting to break in using those credentials would have nowhere to go.

A minor advantage, but still an advantage.

-M

Re:all that for sftp? (1)

evilviper (135110) | more than 6 years ago | (#22509842)

You're welcome to break into any of my systems using a user account that has been disabled, and has no permission to access anything. eg. user "nobody". That's precisely how I would set up a sftp group.

Re:all that for sftp? (0, Redundant)

weicco (645927) | more than 6 years ago | (#22500440)

So you are running Apache as root? Scary.

scponly (0)

Anonymous Coward | more than 6 years ago | (#22501904)

This functionality was already available through an add-in called "scponly" http://sublimation.org/scponly/wiki/index.php/Main_Page [sublimation.org] . Sounds like it'll be easier to deal with when it's directly implemented in OpenSSH, though.

how chroot jails helps you when you got this (1)

zukinux (1094199) | more than 6 years ago | (#22506976)

http://it.slashdot.org/article.pl?sid=08/02/10/2011257 [slashdot.org] simply, it doesn't, unless you want not to allow users to run anything?

Re:how chroot jails helps you when you got this (1)

Just Some Guy (3352) | more than 6 years ago | (#22510400)

it doesn't, unless you want not to allow users to run anything?

Since SFTP stands for Secure File Transfer Protocol, it's not really designed to allow you to execute commands.

Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>