25

I'm setting up on my VPS a vsftpd, and i don't want users be allowed to leave they're ftp home directory. I'm using local_user ftp, not anonymous, so I added:

chroot_local_user=YES

I've read in a lot of forum post, that this is unsecure.

  1. Why is this unsecure?
  2. If this is unsecure because of using ssh to join to my VPS as well, then I could just lock out these users from sshd, right?
  3. Is there an other option for achiving this behaviour of vsftpd? ( I dont want to remove read permissions on all folder/files for "world" on my system )
Castaglia
  • 3,239
  • 3
  • 19
  • 40
p1100i
  • 579
  • 2
  • 7
  • 15

3 Answers3

26

Check here for VSFTPD's FAQ for the answer your looking for. Below is the important excerpt that I think will answer your question.

Q) Help! What are the security implications referred to in the "chroot_local_user" option?

A) Firstly note that other ftp daemons have the same implications. It is a generic problem. The problem isn't too severe, but it is this: Some people have FTP user accounts which are not trusted to have full shell access. If these accounts can also upload files, there is a small risk. A bad user now has control of the filesystem root, which is their home directory. The ftp daemon might cause some config file to be read - e.g. /etc/some_file. With chroot(), this file is now under the control of the user. vsftpd is careful in this area. But, the system's libc might want to open locale config files or other settings...

Community
  • 1
  • Thanks for that, I didn't know all that myself. Learned something! +1 – Yanick Girouard Feb 22 '12 at 22:00
  • 7
    Actually I came here after reading the FAQ because I don't understand this worrying statement: "The ftp daemon might cause some config file to be read - e.g. /etc/some_file. With chroot(), this file is now under the control of the user.". Presumably this would only be the case if `vsftpd` had a security flaw (à la buffer overflow)??? How does running `vsftpd` with users chroot'ed to their home dir make this scenario more likely? Please explain... – sxc731 Mar 02 '17 at 21:06
6

The problem is that you can't both use local accounts and also disable those accounts from shell login. If you set their login shell to /bin/nologin, it won't let you login with vsftpd either.

A better and more secure FTP daemon would be Pure-ftpd. Look it up, it's available from the EPEL repository, and it allows to create virtual users. The server uses a common user/group to set all permissions for the home folders of the users and "maps" the virtual users to that user when it logs in to deal with permissions. That's more secure, and you don't have to deal with openssh login security.

Pure-ftpd also supports a whole lot of features such as quotas, ratios, and such. Much better than vsftpd.

Here's a simple tutorial on how to install it and configure a basic virtual user: http://blog.namran.net/2011/05/04/how-to-setup-virtual-ftp-server-using-pure-ftpd-in-centos/

If you read the full doc (which you should) you'll know that the -d switch when creating the virtual user is an auto-chroot to that directory for that user.

Yanick Girouard
  • 2,295
  • 1
  • 17
  • 18
  • I use the `AllowUsers user1 user2` directive in my sshd_config, where i don't allow the ftp_user1 to login with ssh, still user ftp_user1 is able to login with ftp. So it's working as intented, but still my main question open, why is it unsecure? – p1100i Feb 22 '12 at 14:11
  • 4
    Yes it will! You just need to add the "non-shell" to /etc/shells. On many systems either /bin/false or /bin/nologin exists in /etc/shells. If the shell is there, vsftpd will indeed let you login, also with chroot_local_user enabled. – Frands Hansen Feb 22 '12 at 19:47
  • 1
    I stand corrected then. Thanks for pointing it out! – Yanick Girouard Feb 22 '12 at 21:58
2

When chroot’ed to /some/dir/, the filesystem becomes effectively confined to that directory. Thus, any program attempting to open/etc/some_file effectively opens /some/dir/etc/some_file.

When /some/dir/ is writable, a malicious user can insert a maliciously crafted /some/dir/etc/some_file into it.

The resulting degree of insecurity depends on the underlying software being aware of chroot’ing or not. vsFTPd surely is (as mentioned in the FAQ above), but some library underneath may not.

Laurent CAPRANI
  • 23
  • 3
  • but it does not answer the question, why would it be insecure using chroot – djdomi Nov 04 '21 at 18:02
  • @djdomi I edited my answer to specify "a maliciously crafted `/some/dir/etc/some_file`". The resulting degree of insecurity depends on the underlying software being aware of chrooting or not. vsFTPd surely is, but some library underneath may not. – Laurent CAPRANI Nov 06 '21 at 10:04
  • add these ibfos to the answer not to a comment! – djdomi Nov 06 '21 at 14:47