Jefferson.Ogata at noaa.gov
Fri May 1 10:41:19 EST 2009
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
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
More information about the openssh-unix-dev