Providing /bin and /lib Inside a Chroot Jail – Symlink Guide

Working from the vsftpd version 2.2.2, there are two options for keeping users in a chroot jail:

• chroot_list_enable

Just add users to the chroot list e.g. (/etc/vsftpd/chroot_list) that you want placing in a chroot jail.

• chroot_local_user

This will place all local users in a chroot jail, however, if this is set then the chroot_list becomes a list of users who DO NOT go in a chroot jail.

Therefore check your list does not contain user kg if you have chroot_local_user=YES configured.

Obviously restart the vsftpd daemon after making configuration changes.

Excert from man vsftpd.conf

   chroot_list_enable
          If activated, you may provide a list of local users who are placed in a chroot() jail  in  their  home  directory  upon  login.  The  meaning  is  slightly  different  if
          chroot_local_user  is set to YES. In this case, the list becomes a list of users which are NOT to be placed in a chroot() jail.  By default, the file containing this list
          is /etc/vsftpd/chroot_list, but you may override this with the chroot_list_file setting.

          Default: NO

   chroot_local_user
          If set to YES, local users will be (by default) placed in a chroot() jail in their home directory after login.  Warning: This option has security implications, especially
          if  the  users  have  upload permission, or shell access. Only enable if you know what you are doing.  Note that these security implications are not vsftpd specific. They
          apply to all FTP daemons which offer to put local users in chroot() jails.

          Default: NO

I have configured vsftpd to chroot users and these are the /etc/vsftpd.conf settings that I used (Ubuntu 14.04):

listen=YES
anonymous_enable=NO
local_enable=YES
dirmessage_enable=YES
use_localtime=YES
xferlog_enable=YES
connect_from_port_20=YES
chroot_local_user=YES
chroot_list_enable=YES
secure_chroot_dir=/var/run/vsftpd/empty
pam_service_name=vsftpd
rsa_cert_file=/etc/ssl/certs/ssl-cert-snakeoil.pem
rsa_private_key_file=/etc/ssl/private/ssl-cert-snakeoil.key
allow_writeable_chroot=YES

NOTE: Ensure /etc/vsftpd.chroot_list or /etc/vsftpd/chroot_list are empty.

Once you get it working, if you want to keep track of ftp logins, then you can set session_support=YES and these should then apprear using the last command:

username   vsftpd:12025 IP address     Tue Oct 14 14:05 - 14:10  (00:05)
username   vsftpd:12011 IP address     Tue Oct 14 14:04 - 14:05  (00:00)

NOTE - utmp and wtmp support is only provided with PAM enabled builds.

The explanation lies in the mount.fuse man page:

Filesystems are mounted with nodev,nosuid by default, which can only be overridden by a privileged user

With the nodev option, the kernel bans all access to devices in the mounted filesystem. With the nosuid option, the kernel ignores setuid and setgid attributes. Both options are necessary for security when a filesystem is mounted by a non-root user: otherwise the mounting user could create a setuid root shell or devices letting him access all disks bypassing the filesystem.

You'll also want the allow_other option if non-root users are to access that filesystem.

unionfs-fuse -o cow,dev,suid,allow_other /chroot/files=RW:/chroot/persistent/:/ /chroot/chroot/

If you want to restrict which devices are visible in the chroot, then a union mount isn't the way to do that. Instead, leave dev off and mount a separate filesystem containing your desired minimal /dev. You can make that a tmpfs:

unionfs-fuse -o cow,suid,allow_other /chroot/files=RW:/chroot/persistent/:/ /chroot/chroot/
mount -t tmpfs -o mode=755 chroot-dev /chroot/chroot/dev
cp -a /dev/null /dev/zero /dev/urandom /chroot/chroot/dev
mkdir /chroot/chroot/dev/pts
mount --bind /dev/pts /chroot/chroot/dev/pts

Instead of a tmpfs, you could bind-mount a directory containing your devices ready to go. You'll need to bind-mount /dev/pts to get pseudoterminals in the chroot.