Questions about chroot and Virtualmin.

First and foremost, I am thrilled to have found the *min family of software. I am not a linux newb, however, managing a web-server at the depth I am managing at the moment IS new to me.

I can say I have been able to learn a lot just from the transparent fashion Web/Virtualmin operates on top of linux and other software.

My main question at this point is thus: Should I have configured chroot before installing Virtualmin? I notice that the root folders for the several virtual servers I have created are not jailed in a chroot container. Rather, they are stored in /home and are apparently being served from there. Is that normal? Is it safe? I can’t seem to find a conclusive answer via site search or google.

Thanks in advance!

Post edited by: packetloss451, at: 2009/05/26 04:51<br><br>Post edited by: packetloss451, at: 2009/05/26 04:52

Howdy,

Welcome to *min! :slight_smile:

Yup, that’s certainly normal, and I wouldn’t have done anything differently.

Amongst other issues – to have a usable shared hosting server, by the time you’re done copying all the files you’d require into the chroot environment, you’d have nearly re-created your pre-chroot environment :slight_smile:

However, using Virtualmin with suexec, any web apps for the Virtual Servers you have are going to run as the Virtual Server owner, rather than a generic apache user – so the Linux permissions will protect you at that point.

There’s other problems I’d be concerned about tackling – such as making sure that all the current system updates are in place, and that the web apps being run are at their latest versions and don’t have any security issues in them.

Those are the larger issues that many seem to fall behind on – and even if you were running a fully-functioning chroot environment, someone could still break into a vulnerable web app and use your system to send spam :slight_smile:

Have a good one,
-Eric

Should I have configured chroot before installing Virtualmin?

I would argue you shouldn’t configure chroot ever, if you’re using it for security. There are some pretty significant dangers to using it as a security tool. For one, it breaks some of the security features of ssh. For another it introduces a stage in the interaction with your user where they have root privileges (chrooting requires root privileges). If you make a mistake, or there is any insecure element in your chroot configuration, and an exploit occurs it could be dramatically more dangerous than someone merely seeing a few files in /etc. So, while it makes the system seem more secure at first glance, it actually probably makes it dramatically more likely to be rooted.

In short, we don’t recommend chroot environments. If you need root-like levels of separation, there are good methods for achieving it (Xen, Zones, vservers, etc.), and we have tools for managing those methods (we have a new product in private beta now and entering public beta this week for managing virtualized systems).

What about http://blog.thewebsitepeople.org/2012/10/virtualmin-sftp-chroot:

This guide examines setting up chroot’ed SFTP-only user accounts under Virtualmin.

The Rationale:

SFTP is a secure alternative to FTP and FTPS that uses SSH.  With this setup, no FTP server is needed, as the native sshd server is used instead, SSH does not require an SSL certificate (like FTPS), and is usually considered more secure.

However, one drawback is that FTP servers typically offer a simple config option to “restrict access to the user’s home directory”, whereas SFTP requires a chroot’ed setup to do this, which is more complex, and not supported natively by Virtualmin (or really any other CP).

Note: Giving users access to the full server is not as bad as it sounds.  Users are limited by file permissions as to what they can actually see or do, and Virtualmin sets home directory permissions to 750 by default, so users can’t snoop around each other’s files.  More importantly, restricting access to the user’s home directory only applies to FTP service.  This is just a minor inconvenience for any competent hacker, as access to the full server is easily obtained via the web server (which is not chroot’ed), using any web-based file manager (many CMSs come with one built-in).

However, for the average user, there may still be some value in restricting just their FTP access so as to at least discourage them from snooping around.

There are some complications to overcome:

  • The chroot directory must be root owned and world-readable (sshd checks this unconditionally for security reasons).
  • The user’s home directory should be relative to this root because the server will attempt to go to the directory relative to the root when the user logs in.
  • If you want to prevent users from being able to see even the list of other users on the server, then each user will need a separate chroot directory.

The typical solution involves a complex home directory path:
/home/chroot/domain/home/domain

Note that all directories in the path leading up to the final sub-directory should be root owned and world-readable.

Steps to follow:

1. Set the home directory template in Virtualmin accordingly:

Virtualmin -> System Settings -> Virtualmin Configuration -> Defaults for new domains -> Home directory base: /home/chroot/${DOM}/home

Virtualmin -> System Settings -> Virtualmin Configuration -> Defaults for new domains -> Home subdirectory: ${DOM}

Note that both settings are required, even if ${DOM} is the default, as Virtualmin will not correctly interpolate the directory unless a manual template is set.

2. Add a custom command to handle setting up and cleaning up the chroot:

Virtualmin -> System Settings -> Virtualmin Configuration ->Actions upon server and user creation -> Command to run before making changes to a server: /home/chroot/chroot.sh

Virtualmin -> System Settings -> Virtualmin Configuration ->Actions upon server and user creation -> Command to run after making changes to a server: /home/chroot/chroot.sh

3. Create the /home/chroot/chroot.sh as follows:

#!/bin/ksh

if [ ! “$VIRTUALSERVER_PARENT” ]
then
  if   [ “$VIRTUALSERVER_ACTION” == “CREATE_DOMAIN” ]
  then
    if [ ! “$VIRTUALSERVER_CREATED” ]
    then
      mkdir -p /home/chroot/$VIRTUALSERVER_DOM/home
    else
      echo “Setting up $VIRTUALSERVER_DOM to chroot’ed environment for sftp”

      usermod -d /home/$VIRTUALSERVER_DOM $VIRTUALSERVER_USER
      ln -s $VIRTUALSERVER_HOME /home

      echo " … done"
    fi
  elif [ “$VIRTUALSERVER_ACTION” == “DELETE_DOMAIN” ]
  then
    if [ “$VIRTUALSERVER_CREATED” ]
    then
      echo “Cleaning up $VIRTUALSERVER_DOM’s chroot’ed environment”

      rm -rf /home/chroot/$VIRTUALSERVER_DOM /home/$VIRTUALSERVER_DOM

      echo " … done"
    fi
  fi
fi

And don’t forget to give it executable permissions.

This script:

  • Creates the home directory’s parent directory as Virtualmin will not do this automatically, and fail without it.
  • Changes the /etc/passwd home directory entry to be relative to the chroot (so it’s not the same as the real home directory!).
  • Adds a symbolic link from this home directory location to the real directory for convenience so that things like ~domain still work.

4. Add Virtualmin users to a secondary group that sshd can identify for SFTP-only access:

Virtualmin -> System Settings -> Server Templates -> Default Settings -> Administration user -> Add domain owners to secondary group: sftponly

Be sure to create this group.

5. Update /etc/ssh/sshd_config to set SFTP-only access for members of this group:

Subsystem       sftp    internal-sftp
Match Group sftponly
        ChrootDirectory /home/chroot/%u
        ForceCommand internal-sftp
        AllowTcpForwarding no

6. Reload sshd:

>systemctl reload sshd.service

7. Test the setup by creating a user, logging in via SFTP, and attempting to log in via SSH (hopefully unsuccessfully).