Chrooted rsync over ssh

Bob tlcbob01 at yahoo.fr
Thu Jan 13 18:41:41 GMT 2005


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


More information about the rsync mailing list