ChrootDirectory %h

[Jefferson Ogata]

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