ChrootDirectory %h

[Peter Thomassen]

Hi,

many people are having problems using SFTP with ChrootDirectory when the 
jail directory (or the path above) is not owned by root. The question is 
if chroot'ing to usual home directories can be allowed, even though they 
are owned by regular users.

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 ~`.


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

2.) In most cases, the user can execute the setuid binary using another 
execution chain, for example if
- he's got a web hosting account and can execute it using a CGI script, 
or if
- he logged into the machine locally. Why should the level of security 
depend on whether the session is a remote or a local one, and why should 
different restructions be imposed?

3.) Assuming the chroot directory (and the path above) is owned by root, 
people will create directories therein that the SSH user can write to. 
How is ensured that there isn't any setuid binary placed in this leaf 
directory that can be executed by the user? How is security increased by 
the adding a directory level?

4.) A common application is to grant users SFTP access using the 
internal-sftp feature, and to force them into their home directories. 
Those users can't execute any binaries because command execution is 
handled by internal-sftp. In this case, there is absolutely not risk 
coming from setuid binaries.
Suggestion: If ChrootDirectory is applied together with ForceCommand 
internal-sftp in the same context (configuration wide, or in a Match 
block), do not check for root ownership.

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.

6.) In <alpine.BSO.1.10.0811130008360.28508 at fuyu.mindrot.org> it was 
stated that "allowing a user write access to a chroot target is 
dangerously similar to equivalence with allowing write access to the 
root of a filesystem". The difference is that the root of a filesystem 
is accessed by (and must be operational for) many people, while a home 
directory only is used by one user. According to common philosophy, 
every user has the right to destroy his account using setuid binaries. 
He also could do `rm -rf ~/*`.
Suggestion: Drop the ownership check in case of ChrootDirectory %h. In 
this case one can be sure that the security of other users is not affected.

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.


Additionally, it is often suggested to set up a user-specific container 
directory (e.g. /home/user1container/) that is owned be root and 
chroot'ed to, and to create a user-writable directory therein 
(/home/user1container/user1/). The latter one, seen relative from the 
container directory (/user1/), than can be defined as the user's home 
directory in /etc/passwd so that OpenSSH automatically chdir's there 
after login. Often, this is not very pratical, since there are other 
services running outside the chroot jail that also need access to the 
user's home directory, such as MTAs or the Apache web server with the 
UserDir module (à la http://www.example.org/~user1/). Those services 
can't find the user's home directory if configured as described above.

Please consider my remarks and tell me if I got anything technically wrong.

Thanks,
Peter