chroot howto for sftp-server

[Manfred Heubach]

Dear Dan,

of course you're right. I should have mentioned that this patch may open security holes and that everybody has to decide on his own wether to use this patch or not. Sorry for that!

But back to a possible solution:
1. If I change the patch to access the information from passwd this solves the $HOME issue.

2. Then we could change the directory for chroot to something like /home/username/chroot instead of the home directory itself. This would prevent the users from accessing the home directory and .ssh at all.

(My instructions suggested to chown .ssh to root:root and chmod it and all files in it to 755 (I looked into my howto right now and this is really bad because there I told to chmod 766 - which is complete bullshit). If .ssh is owned by root and 755 then users can read files from .ssh but not change them or upload files to .ssh. Furthermore I mentioned that I have the homedirs themselves owned by root and only readable for the users. This - of course - should have been recommended.)

3. Sanity checks on the chroot target are beyond my scope. As I already told I'm not very up to date with programming.


Regards
Manfred


----- Original Message ----- 
From: "Dan Astoorian" <djast at cs.toronto.edu>
To: "MH - Entwicklung" <entwicklung at heubach-edv.de>
Cc: <openssh-unix-dev at mindrot.org>
Sent: Wednesday, December 19, 2001 4:46 PM
Subject: Re: chroot howto for sftp-server 


> On Wed, 19 Dec 2001 02:32:25 EST, "MH - Entwicklung" writes:
> > 
> > I can see a problem for "trusted" users who login via ssh then 
> > manipulate their $HOME and then invoke the chrooted sftp-server. They 
> > will be able to access directories they shouldn't have access to. And if 
> > file permissions under this directories are set in a lax way this really 
> > means that users can access files they shouldn't see at all.
> 
> The problem is greater than this: it's an avenue of attack for these
> users to *crack root*.  Applying your patch and making sftp-server
> setuid-root makes the system less secure, not more; and forgive my
> bluntness, but providing instructions that advise people to apply a
> half-assed patch with no mention of the potential holes it opens up is
> just plain irresponsible.
> 
> > The only way to prevent this is to give no shell login to anybody. 
> 
> No, a better way to prevent the trusted-$HOME problem is to use the
> /etc/passwd entry (i.e., getpwnam(getlogin()) or getpwuid(getuid()))
> instead of an environment variable which the user can manipulate.
> 
> Ideally there should still be additional sanity checks on the target
> directory, but at least this puts the responsibility for ensuring that
> the target is secure into the hands of the system administrator.
> 
> On that topic, your instructions advise controlling the permissions and
> ownership of the ~/.ssh directory, but doesn't talk about setting up and
> controlling the chroot() target or the user's home directory itself at
> all.
> 
> Also, I think there's already been consensus here that it would be wiser
> to chroot() to a subdirectory of the user's home directory, rather than
> the home directory itself, in order to avoid an entire class of attacks
> (such as manipulating ~/.ssh, uploading dot files which may be used to
> cause other programs to run commands, e.g., ~/.bashrc, ~/.forward,
> etc.).
> 
> > If I'm completely wrong with trusting $HOME please let me know.
> 
> You're completely wrong with trusting $HOME.  :-)
> 
> -- 
> Dan Astoorian               People shouldn't think that it's better to have
> Sysadmin, CSLab             loved and lost than never loved at all.  It's
> djast at cs.toronto.edu        not, it's better to have loved and won.  All
> www.cs.toronto.edu/~djast/  the other options really suck.    --Dan Redican
>