Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

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.

share|improve this question
add comment

2 Answers 2

up vote 1 down vote accepted

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

share|improve this answer
    
Thanks for the information. I did attempt to use the Match block, when restarting the ssh service, it dies (unless i remove the match block). However, after after reviewing the comment below, is there a better way to achieve my goal? –  Ash May 30 '12 at 7:34
    
Then you probably have a syntax error in your Match block. Your syslog will have details; you can also start sshd in debugging mode (/usr/sbin/sshd -d). Pierce is correct that there are limits to the use of chroot as a security mechanism. I would strongly suggest looking into Linux containers (lxc.sourceforge.net) for this purpose. –  larsks May 30 '12 at 11:56
add comment

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.

share|improve this answer
    
After reviewing this notice, I've revised, and updated my initial request. Expressing my ultimate goal, I think chrooting may not be what I need. –  Ash May 30 '12 at 7:49
    
You can use LXC (linux containers), which are much more secure than a traditional jail while not requiring mucking about with kernel patches. lxc.sourceforge.net –  larsks May 30 '12 at 11:54
    
I think I will look into the alternative you have both suggested, a little research and so on (: Thanks –  Ash May 30 '12 at 14:02
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.