SSH/sandbox/chroot folder

Message

s243a · #1 Post by **s243a** » Sun 16 Feb 2020, 06:21

Intro

openssh gives you the option to specify a chroot directory. This provides a way of protecting your system from an attacker that has gained unauthorized access to your ssh server. The chroot folder presumably could be anything from a simple chroot to full-out linux container. oppenssh has an option to have privilege separation, so with this option one might expect more isolation then the standard chroot enviornment.

An application of an ssh chroot folder (key transfer)

SSH communication via the public/private key pair model is typically more secure than password based authentication, presumably due to the length of passwords that most people use. The situation is even worse if one uses the default password. A common attack to a network service is to try the default passwords.

So in this example, we are going to consider a low threat scenario. We want to transfer public keys between two ssh servers over the local network. Possible threats could be malicious process ruining on one of the devices in the network, or someone that hacked into the wifi network.

The likelihood of such threats is low, under the assumption that the user is practicing safe surfing habits and is not a person of interest from a skilled adversary like an inelegance agency. However, since these threats might be present, we don't want the default password to give access to our full system. Also we consider the consequences of an attack to our system minor. This assumption depends on what data you are protecting.

The solution is to run the ssh server in a chroot directory, use scp [6] to copy the keys and once the keys are copied then disable password based authentication. If in the odd chance someone hacks the system in this interval then we should see changes in the save layer. If the save layer is minimal, then such changes should be easy to identify.

To do this we might push any changes that we want into an sfs file like the adrv prior to setting up our chroot system. For a live system, you can use nic007's script to save changes (or remaster?) to an adrv. For a sandboxed system, you can use my remaster sandbox script. Alternatively, you can use the official puppy scripts to do a full remaster.

Alternative approaches, which don't directly use ssh

Rather than using ssh to transfer our public keys, we could use a third party service like dropbox to transfer the keys, which presumably add some privacy and also the risk of an attacker being able to utilize a public key in an attack is low. Finally, we could after we first establish an ssh session this way using public keys we could transfer new public keys once the ssh session is established that dropbox doesn't know about and delete the old keys.

If this second transfer was done over a private network the chances of the secondary key transfer being intercepted would be very low but if one is really paranoid then use a hardwired network equipment, or for even better security transfer via removable media (a usb key).

One could also encrypt the ssh key prior to transferring it over the ssh connection. Much of this would be overkill in most instances but depending on the cost and the expected threat level it may be prudent to be overly cautious.

Create your chroot system

Prior to starting the ssh server we want to create a chroot system to isolate our main system from attacks. I created one from pebee's arch32pup ISO as follows:
1. Download the ISO and delta file to a folder
2. Click on the delta file to apply the delta (I believe this requires the xdelta package)
3. Click on the newly generated ISO file to mount it.
4. Copy the files in the ISO to a new folder.
5. Clone my psandbox, project (or alternativly download it as an archive and extract it).
6. In this newly created folder (Step #4) create a script called "run_sandbox.sh", that looks like this: