Skip to main content

Chrooting User in VSFTPD

For FTP Server, i personally like VSFTPD, since it's very small in size, easy to configure, and it's very secure. You also have two kinds of options for starting the vsftpd daemon, either via inetd or standalone (i would prefer the first one though).

Few days ago, one of my friend asked me a FTP configuration that could prevent users to go up to the root level. I said that VSFTPD should have prevent that, but when i tried to reproduce, it seems that the default configuration didn't enable this option: chroot_local_user=yes. The results? User who have a local account can access the whole system, including getting the /etc/passwd or /etc/shadow password (even though he had to crack it to get access for all system). This is not a good default configuration. So i asked my friend who is working as a sysadmin in my campus. He used proFTPD, but he managed to look the VSFTPD configuration for me, and he found the chroot_local_user option. Here's the description for that option from VSFTPD's Man Page:
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'm quite confused with the security implication. I thought it would be a good idea to place users on their home directory and not other place. Can somebody give a good explanation on this?

Popular posts from this blog

Running Rsync Via Proxy

One way to get the latest Slackware updates is by running rsync to syncronize your local repository and the main repository that hold the Slackware packages. Eric Hameleers has provided a great script called rsync_current.sh and how i modified this tool has been discussed on my previous post. In general, it works, except for one problem, when your computer is connecting to the Internet through a proxy.

My workstation at my office is connected to the Internet through a proxy, so i can't use normal rsync to work normally. I browsed the web and i found this site which tells us about how we should modify our squid configuration to allow rsync connection from any computer from our local networks. I asked my sysadmin to try this script. He agreed and he updated the squid configuration on the proxy.

Next, i need to update my environment variable RSYNC_PROXY to the host of the proxy and also the port. Let's say you are running a proxy on 192.168.1.1 and port 8080, then you need to run …

NVidia Legacy Unix Driver Update

NVidia has released an updated legacy drivers to support X.Org 1.19 with ABI 23. It has been mentioned in the UNIX drivers, but you can directly find the drivers from the links below:
NVidia 304.134 (x86x86_64)NVidia 340.101 (x86, x86_64) I have tested the 304.134 driver and it's working great here. I can finally remove x from my /etc/slackpkg/blacklist file since it's a showstopper for me.
Aside from legacy driver, NVidia has also released their latest driver 375.26 (x86, x86_64), which brings support for newer cards and also many new features (including X.Org 1.19 with ABI 23 support). 

Security Update: firefox, irssi, pidgin

Three security updates were released for today:
firefox: Upgraded to 45.4.0esr for 14.1 and 14.2 and 49.0 for currentirssi: Upgraded to 0.8.20pidgin: Upgraded to 2.10.11, 2.10.12, and 2.11.0 for all stable Slackware releases depending on their support Some minor update in current:
mkinitrd: Add dmsetup supportemacs: Upgraded to 25.1qt: Fix multilib issue network-scripts: Fix minor issue