Ubuntu SFTP & Chrooting

Question

I've been looking around for a few days now, playing around with configurations and following tutorials on this.

I Have two groups: dev and sftp.

Users within the dev group are also part of the www-data and svn groups. These users are to be chrooted to their home directory. I would like them to have access to /var/www either via a symbolic link, or somehow mounting the directory for them.

Users within the sftp group, cannot ssh, but should be allowed to sftp.

Background

I attempted to configure the sshd_config to allow sftp group sftp only access, restarted ssh and it dropped. Fortunately when dealing with the sshd_config I prepare a failsafe to revert the config and restart by cron every 10 miniutes in this event. Nevertheless, I couldn't find an alternative or get this method to work.

Edit !!

After reviewing the answers below, would an alternative be advised? I run Ubuntu - therefore the root user is locked, and ssh_config rejects root login. Also sudoers has 2 permitted groups within its config, srv-admin and sudo (sudo cannot kill, reboot, upgrade etc).

The group dev is to allow the user access to 2 directories, /home/<user> and /var/www. The group sftp is ONLY to allow the user SFTP access, nothing more, and NO SSH.

Sounds like I'm misunderstanding the use of chroot in thus scenario.

Answer 1

You cannot expose a directory outside of a chroot environment via a symbolic link (because the path simply won't be accessible). You can expose the directory via a bind mount. This lets you mount one part of your filesystem on another part of your filesystem. For example:

mount --bind /var/www /home/someuser/www

In general, chroot environments are tricky unless you are really limiting the number of tools available. You will need to provide an appropriate set of binaries inside the chroot environment, as well as all the necessary shared libraries. This usually ends up being a losing proposition for an interative environment (such as provided with an ssh login) if people expect to be able to work normally.

You should be able to provide sftp-only access to the sftp group using a Match block in your sshd_config along with the ForceCommand directive. Something like:

Match Group sftp
ForceCommand sftp-internal

You can include a ChrootDirectory option as part of your Match block. The following would chroot people to their own home directory:

ChrootDirectory %h

Note the following from the sshd_config man page:

The ChrootDirectory must contain the necessary files and directories to support the user's session. For an interactive session this requires at least a shell, typically sh(1), and basic /dev nodes such as null(4), zero(4), stdin(4), stdout(4), stderr(4), arandom(4) and tty(4) devices. For file transfer sessions using “sftp”, no additional configuration of the environment is necessary if the in-process sftp server is used, though sessions which use logging do require /dev/log inside the chroot directory (see sftp-server(8) for details).

Answer 2

Remember, chroot is for build environments, it's not a security tool. There are countless ways for attackers to break out of chrooted environments.

If you are looking to isolate users from each other, the regular permissions model in Linux should be enough, but you need to lock down the environment itself. Always assume that an attacker is going to break out of the chroot, and lock down from there.

If you want real isolation, a KVM/Xen style solution is probably what you want, but if you insist on using chroot, then you probably want a grsec patched kernel that has some basic security protections that will prevent the most common chroot breaking techniques.