ChrootDirectory %h

[Chris Wilson]

Hi Peter,

On Thu, 30 Apr 2009, Peter Thomassen wrote:

> I know that this topic has been discussed on the list several times now, 
> so I searched the list archives for posts that invalidate the following 
> arguments, but I couldn't find any.
>
> 1.) SSH aims to provide an environment that makes the user feel like
>     sitting in front of the physical machine, having logged in locally.
>     Chroot'ing gives the additional feature of restricting filesystem
>     access to a specified part of the tree, nothing more. Especially, it
>     should not distort the kind of actions the user could take if he
>     logged in locally and did `chroot ~`.

As far as I know, only root can chroot. Does that invalidate your 
argument?

> In <alpine.BSO.2.00.0903291837370.31551 at fuyu.mindrot.org> it was stated that 
> the main reason for not relaxing this restriction is that setuid binaries 
> could be executed. This argument isn't substantive (see arguments 2 to 5):

I think the argument is that setuid binaries can be *fooled* into doing 
something dangerous when the user can chroot, e.g. they can be made to run 
/bin/ls as root where /bin/ls is actually whatever the attacker wants to 
run as root.

> 5.) In case that the setuid argument still holds, one can check if the
>     filesystem containing the chroot directory in question is mounted
>     with the nosuid option, e.g. by looking at /etc/mtab. If so, there
>     is absolutely not risk coming from setuid binaries.

Is that portable? I'd guess not.

If SFTP does not allow executing binaries at all then I guess it's moot.

> 7.) Not only the user has the right to destroy his data. The system
>     administrator (who always must be assumed to have a certain
>     sensibility for security topics, especially when dealing with remote
>     access) also has the right to lower security barriers. He also can
>     decide not to use a firewall, or to do `rm -rf /`. Please allow him
>     to decide the question of setuid binary execution inside a chroot
>     target.

Fair enough, but it should not be enabled by default. It should be a 
EnableChrootToUserDontBlameSsh = yes option.

Cheers, Chris.
-- 
_____ __     _
\  __/ / ,__(_)_  | Chris Wilson <0000 at qwirx.com> - Cambs UK |
/ (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer |
\__/_/_/_//_/___/ | We are GNU : free your mind & your software |