ChrootDirectory %h

[Jefferson Ogata]

On 2009-05-02 17:17, Peter Thomassen wrote:
> But what about this (--> <gtccd8$p1q$1 at ger.gmane.org>)?
>> 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.
> 
> Do you think it is practical and justifiable in terms of security to
> relax this constraint in the limited scope of SFTP?

This is a good example of the problem. If there is a bug in the SFTP
code that allows arbitrary code execution (a buffer overflow, for
example), the risk when chroot to a user-controlled directory is allowed
is dramatically higher. I can understand the developers not wanting to
take that risk.

If we could be certain that the sftp-server could never have such a bug,
then perhaps it would more palatable. But I think the design philosophy
with sftp is to assume that someone who has sftp access also has shell
access with the same constraints. The expectation is that filesystem
permissions should be able to achieve the limitations that you desire;
in general users' home directories should not be readable by all. In the
particular case where users are uploading content to be published by a
web server, there may be alternate ways to accomplish this using bind
mounts or some similar strategy.

For example, you can put all your web user home directories under a
common path /home/webusers, chroot all those sftp users to
/home/webusers, make all those home directories mode 700, give each user
a subdirectory for web content (e.g. public_html) that is mode 755, and
bind mount each user's web content directory under an alternate path
(e.g. mount -o bind /home/webusers/user1/public_html
/public_html/user1), and configure your httpd to use /public_html/* for
user content. On a large system this can end up with an unwieldy
collection of bind mounts, but it's a workable strategy.

Or, as I suggested, you can write your own patch to relax the
ChrootDirectory restriction and make it part of an automated openssh
build, e.g. using rpm.

-- 
Jefferson Ogata <Jefferson.Ogata at noaa.gov>
NOAA Computer Incident Response Team (N-CIRT) <ncirt at noaa.gov>
"Never try to retrieve anything from a bear."--National Park Service