I have posted on this mailing list to ask if using realpath() in a
dummy-shell to chroot a user was secure. Since it is not, i have coded a
dummy shell that uses both chroot() and a virtual root.
Here is what it does :
Suppose that you have a user called "alpha".
His home directory is /home/alpha
I want this user to be allowed to use rsync over ssh, but i don't want
him to have a shell access (so he can't execute anything on the server).
In his home directory, there are bin, sbin, lib, usr, dev... dirs,
becaus it is a jail. The "ftp" directory contains the files of this
user. It is the only directory the user should have access to. Using
rsync in these conditions would imply the user to uses a path like
"/ftp/files". But he could also read the bin, lib, ... directories. I
don't want that either (not for security reasons, but to make simpler).
So when the user want to access <path> with rsync, the dummy-shell
replaces <path> by /ftp/<path> before calling rsync. I uses
realpath()
to ensure that the user don't uses ".." or symlinks in the path.
Here is the dummy-shell : source code
http://www.coldsource.net/projets/dummy-rsync/main.cpp.gz
What about the security ?
realpath() is not secure, but since the dummy-shell uses chroot() the
user won't have acces to any files he shouldn't. In the worst case, he
could have access to the bin, lib... directories, which is not important
because the files are owned by root, so the user can't modify them, nor
create new ones.
However, since the user doesn't have a shell access, it is almost
impossible to break realpath() security by modifying a symlink...
I don't think that this security can be broken (especially without a
shell access), however, if someone find a bug in the source code, it
would be nice to inform me.
I'm waiting your opinions
Thanks, Bob
