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