On Sat, May 2, 2015 at 9:05 AM, Stephan Leemburg <sleemburg@xxxxxxxxxxxxx> wrote: > Hi Damien, > > Thank you. I read the rationale. > > Just to summarize, a user writeable chroot target is considered dangerous > if: > > 1) the user has another way of gaining non-chrooted access to the system > 2) is able to create hardlinks to setuid-binaries outside of the chroot tree Improperly secured symlinks are a similar though not identical problem. The operating system does not know how to prevent a symlink inside a chroot cage from being allowed to write a system-read file for which that nominal chrooted user has privileges. Hilarity can ensue. > 3) there are bugs somewhere that allow privilige escalation or remote > execution of other programs I've been reviewing some of this lately, related to sftp, scp, and rsync chrooted targets managed thorugh the 'rssh' software. There are fascinating escalations that can happen. For example, 'suid' and 'sgid' are related but independent properties > While all these arguments are legitimate, as can be - indeed - seen in > CVE-2009-2904, I believe that there are also other situations. > > In our setup, we have users that currently only have vsftpd chrooted access. > Their login shell is /sbin/nologin and they do not have any other way of > accessing the system. So for this particular setup 1 and 2 are not > applicable. vsftpd doesn't keep the vsftpd binary, itself, inside the chroot cage or any loadable libraries that might be found there. That is part of where the problem comes from: you have to bring in quite a lot of components tools to allow sftp or scp or ssh over rsync to operate inside such a cage. And if you bring in copies of files, rather than hardlinks or symlinks, how do you make sure they stay updated when you update system OpenSSH or system libraries? That is partly why I spent time recently on updating a 'mkchroot.sh' script precisely for rssh users, at https://github.com/nkadel/rssh-chroot-tools. > I think 3 is not related to sftp chroot only, but in general. > So, in my opinion there are use cases that would not compromise security by > having the last component of the chroot sftp directory be owned by the user. > If this could be a configurable option, then administrators that want to use > such a setup could do so by explicitly allowing it. If they can do an rsync, or write directly to it, they can re-arange and replace bin or lib. That's pretty close to the core of the concern. I freely admit that in almost cases where people really need a chroot cage, OpenSSH cages are the wrong solution. vsftpd works pretty well. Git works well, and gets revision history, for recording changes. Even WebDAV over HTTPS can work pretty well, and none of those have to have anything owned by root or run as a root user inside the chroot cage. If you *must* use chroot cages, you might look at using rssh as a wrapper for it. It's a lot easier, and more stable than trying to maintain the patched OpenSSH often used for full chroot cage operations. > Is that something you could live with? If so, can I create a patch and send > it in? > > Again, thank you for the pointers. I had trouble finding them with just > plain search engine lookups. > > Kind regards, > Stephan _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev@xxxxxxxxxxx https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
