Using a live distro for security-sensitive tasks

[rufwoof]

Yes, I've blocked ssh from external as I've been experimenting with EasyOS

As part of standard ssh server you can set a chroot to run. However its trivial to break out of a chroot if you can chroot within that. The answer is to drop the chroot capability (i.e. at the kernel level).

Currently the way I have things set up is that userid 'ssh' is listening to incoming ssh connections and its shell script (instead of /bin/sh for instance) su's to aufs mounts a changes folder along with the main Easy sfs to a top folder, but where the chroot capability is dropped for that and only then chroots into the top (top layer) folder as su spot.

Puppy/EasyOS is odd in that it uses busybox su and if you set that setuid so spot/ssh or whatever can su, then the whole of busybox becomes setuid root - a potential security risk. But if the main system has that set and incoming ssh connections run a chroot (easyOS container) that doesn't have su setuid, then that risk is mitigated.

Currently I have that set so the changes folder is just deleted after disconnection, so a pristine EasyOS connection for each new ssh. Could easily be made persistent but best to have it just reset to the clean boot each time IMO. I've remastered the main EasyOS sfs for that purpose (layout). I've also set it to be cli only (so primarily targeted as being for tmux type purposes/uses) - no X forwarding. But could just as easily have X forwarded and be gui/X based. For cli only it makes the client (remote) end that much simpler, just need a vmlinuz/initrd with busybox and ssh support, perhaps a 20MB boot. For X, the client would also need a X based boot (200MB - 300MB typically).

Presently I'm using hashbang.sh as a Socks proxy, so all http(s) traffic routed through that, and with a small firefox tweak that also disconnects any dns leakage. So conceptually a remote client could ssh in using a minimal 20MB boot which in turn routes all http traffic via a ssh tunnel with no dns leakages. Whilst being relatively quick (socks proxying is quicker than tor or vpn). If the client, ssh server and socks proxy are in three different jurisdictions, perhaps with barriers to the free sharing of information, then that's moderately anonymous. More so if set up on a liveCD type setup, with periodic reboots (runs in ram, contents (records) lost after a reboot).

[rufwoof]

Running a quick test of ssh from London (local) to New York, and then ssh back to my local ssh userid, and then ssh from that to Atlanta ... and operationally seemingly runs just as quick as if I'd just straight ssh to Atlanta for mail/irc ..etc. And that's at business day times, so a good sign (given a 10,000+ mile end to end distance).

[rufwoof]

Looks like EasyOS supports sudo. So I can use that instead of having to mess with setuid of busybox.

For user 'ssh' I've added to the end of /etc/sudoers ...

Code: Select all

ssh ALL=(ALL) NOPASSWD: /mnt/sda1/chroot-cli-2.sh

and for user 'ssh' shell in /etc/passwd it has

Code: Select all

/mnt/sda1/chroot-cli.sh

(instead of /bin/sh) and where in that chroot-cli.sh script it has

Code: Select all

sudo /mnt/sda1/chroot-cli-2.sh

So logins to user 'ssh' result in /mnt/sda1/chroot-cli.sh being executed, which sudo's chroot-cli-2.sh ... which as root sets up the chroot environment (mounts main sfs, auf mounts that with a changes folder to yield a 'top' folder, that is then chroot'd into (with chroot capabilities dropped) and su spot within that).

So fundamentally, ssh into 'ssh' userid results in spot running inside a chroot container with chroot capabilities dropped. Where the main EasyOS sfs is mounted as that chroot's bottom layer, 'changes' folder aufs mounted with that (to record any changes), and 'top' as the top layer - that is the folder that user 'ssh' chroot's into (and runs as spot within that).

A neat feature of doing things this way is that the chroot environment is quick to set up and the overheads are very low - being just to set up a sfs mountpoint (just dir entries and inodes of the main EasyOS sfs), a empty initial changes folder and a top layer that is the aufs merging of that main sfs and changes folder content - that is the folder that is choot'ed into. Takes up near no space. And each unique ssh login could be set to have its own unique chroot environment, distinctly separate from each other (just have to parameterise the chroot-cli.sh/chroot-cli-2.sh scripts to use unique 'changes' and 'top' folders for each individual ssh login).

Adding a additional mount-bind could have those individual choot'ed environments all sharing a common 'shared' folder. For instance for a common message or file sharing area.