ssh user chroot/jail

sneakyimp · 08-21-2017, 10:59 AM

I have been tasked with creating two ssh users that are mailed:
1) datasample - needs to connect via ssh and check load averages and memory usage using free and uptime commands
2) filefetch - needs to connect via scp from remote machine to fetch a file

I have followed the instructions here and here and have created a /var/jail directory. This does indeed seem to have worked for the most part. When I connect as my new user datasample, I am clearly jailed and only the ls command is available.

The problem I'm having is that apparently I need access to the proc directory if I am to check free & uptime and I'm not sure how to grant access to the actual real, non-jailed, living, breathing proc directory. I'm also concerned about the security implications of granting access to this dir. When I try to execute the uptime command as a jailed user, I get this error:

Code:

$ uptime
Error: /proc must be mounted
  To mount /proc at boot you need an /etc/fstab line like:
      proc   /proc   proc    defaults
  In the meantime, run "mount proc /proc -t proc"

Similar results for free:

Code:

$ free  
Error: /proc must be mounted
  To mount /proc at boot you need an /etc/fstab line like:
      proc   /proc   proc    defaults
  In the meantime, run "mount proc /proc -t proc"

Can anyone suggest how I can securely make these commands available to my jailed datasample user?

Turbocapitalist · 08-21-2017, 11:10 AM

You would have to recreate a subset of the main system inside the jail, containing the parts relevant to its operation. I'm not sure how much "security" that will add anyway and the difficulty and complexity levels are very high.

What you might consider instead is using separate keys for each pre-programmed command or script. Then lock those keys to their commands or scripts. Then disable password authentication for that account so that only the keys can be used. Since they would be locked down, it would be quite safe.

See the manual page section "AUTHORIZED_KEYS FILE FORMAT" in the paragraph command="" for details.

Code:

man sshd

For the file fetching, I would strongly recommend to forget about scp and use SFTP instead. scp is all but impossible to lock down but SFTP has good built-in chroot capabilities. You can use it with keys in conjunction with the -b option for batch processing. If you really want to lock that down, depending on how recent your version OpenSSH Server is, you can launch the SFTP subsystem read-only or even whitelist specific requests. See the -R and -p options:

Code:

man sftp-server

justmy2cents · 08-21-2017, 01:49 PM

For a chroot process to be able start successfully, you must populate the chroot directory with all required program files, configuration files, device nodes, and shared libraries at their expected locations relative to the level of the chroot directory. But chroot jail processes are limited only at the file system level, as they still share users, hostname, IP address, etc.. So maybe you can use a ~/.rhosts file to execute the ruptime command with the privilege of another user? Also the danger of giving access to /proc is that /proc holds information about all the containerized processes. This includes environment variables, which are also stored in the /proc pseudo-filesystem, meaning that your host machine has access to the environment for all your running containers. This potentially has security consequences if you're passing secrets like certificates or database passwords into your containers through environment variables.

sneakyimp · 11-10-2017, 11:39 AM

A belated thank you to both of you for your answers.