Mailing List Archive: OpenSSH: Dev

ChrootDirectory %h

Index | Next | Previous | View Threaded

mail at peter-thomassen

Apr 30, 2009, 7:25 AM

Post #1 of 5 (980 views)
Permalink

ChrootDirectory %h

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

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

chris at qwirx

Apr 30, 2009, 12:53 PM

Post #2 of 5 (933 views)
Permalink

Re: ChrootDirectory %h [In reply to]

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> 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 |
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Jefferson.Ogata at noaa

Apr 30, 2009, 5:41 PM

Post #3 of 5 (924 views)
Permalink

Re: ChrootDirectory %h [In reply to]

On 2009-04-30 14:25, Peter Thomassen wrote:
> 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?

You need to understand the sort of scenario that exists when you allow
users to control a directory that someone chroots to.

Let's suppose user home directories are on the same filesystem as /bin.
This is becoming an increasingly common scenario as fewer sysadmins
learn how to partition filesystems. In this case, a user can construct
his own little root filesystem somewhere under his home directory by
copying necessary binaries and libraries, and populate it with his own
/etc/passwd and /etc/shadow. He can also hard link /bin/su under this
mini root filesystem, and this file will still be owned by root with the
setuid bit set.

If you ever let the user chroot to this directory and execute his
hard-linked /bin/su, he can become root within that directory and then
escape the chroot. Even if you could prevent him from escaping chroot,
he can create device nodes and operate directly on filesystems, mount
/proc and operate on external processes, etc. It should be clear that
this is Very Bad (tm). This is a principle reason why chroot() is
limited to the superuser.

Actually preventing this scenario, while still letting users operate in
a chrooted environment at all, is relatively tricky, especially in a
portable program, so careful developers like to stay far, far away from
any possibility of it, lest the odd coding error yield a root shell, and
blame for compromises fall on the developer.

> 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?

It isn't necessary to ensure that. But it is necessary to ensure that
the user can't also construct a false authentication environment which
the setuid binary would unwittingly rely on in a chroot scenario, e.g.
by building his own /etc/passwd. That is what the ownership test is
designed to achieve.

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

The system administrator also has the ability to tweak the code to his
heart's content.

--
Jefferson Ogata <Jefferson.Ogata [at] noaa>
NOAA Computer Incident Response Team (N-CIRT) <ncirt [at] noaa>
"Never try to retrieve anything from a bear."--National Park Service
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

mail at peter-thomassen

May 2, 2009, 10:17 AM

Post #4 of 5 (914 views)
Permalink

Re: ChrootDirectory %h [In reply to]

Hi,

Jefferson Ogata schrieb:
> You need to understand the sort of scenario that exists when you allow
> users to control a directory that someone chroots to.

I now understood the security implications; thank you for your explanation.

But what about this (--> <gtccd8$p1q$1 [at] ger>)?

> 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?

Because the problem raises mainly in the context of SFTP, this would
help a lot of people.

Have a nice weekend,
Peter

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Jefferson.Ogata at noaa

May 2, 2009, 2:00 PM

Post #5 of 5 (920 views)
Permalink

Re: ChrootDirectory %h [In reply to]

On 2009-05-02 17:17, Peter Thomassen wrote:
> But what about this (--> <gtccd8$p1q$1 [at] ger>)?
>> 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>
NOAA Computer Incident Response Team (N-CIRT) <ncirt [at] noaa>
"Never try to retrieve anything from a bear."--National Park Service
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev [at] mindrot
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads