new openssh (new paranoia-patch)

Bennett Todd bet at rahul.net
Wed Aug 18 08:13:46 PDT 2004


2004-08-18T13:57:57 Rainer P. Feller:
> A loginserver, you log into an environment where every single
> executable file is on a read-only-filesystem if a file is on a
> r/w-filesystem it is not executable, /lib/ld-linux.so belongs to
> nobody and has a s-flag in this loginserver there are 3 network
> interfaces and you want every traffic into the loginenvironment to
> come trough eth0 and every traffic out of the loginenvironment to
> eth1 you don't want anybody to be able to use the 3rd interface
> which is connected to a backupserver. then you have to be able to
> override comandline parameters given by a user and for this you
> need to patch the ssh-client.

Ahh, I think I see.

I've set up something with a vaguely similar flavour. I chrooted the
sshd, in the chroot jail the /etc/passwd specified a custom shell
that just execed an ssh client to a next-hop machine, sshd
configured to allow no port forwarding. The users never get to
specify the ssh client cmdline or env.

If you want to let the users out onto a shell where they can then
invoke the ssh client while keeping control, I'd probably tighten
the screws a little more, I'd build the server entirely of
statically linked executables and leave dynamic linking machinery
entirely off it, no ld.so at all (which has been able to be used to
run arbitrary executables even if their execute bit wasn't set).
uClibc is good for this. Busybox is very nice in such a mix.

Combine that with readonly mounts of the bits where executables live
and noexec mounts of writeable filesystems and it'd get a bit
trickier to burgle. Keep everything minimal to reduce the number of
breeding grounds for bugs people could use to run arbitrary code. No
dynamic modules in the kernel, no support for loading 'em. No
daemons that you can possibly omit. No suid executables on the
system at all, no daemons listening on network ports but the
carefully configured sshd.

Hmm. Why let anything be writeable at all? How about running the
entire server off a readonly initrd containing four files: busybox,
sshd (I'd probably try dropbear), an ssh client, and
/etc/init.d/rcS, the three executables statically linked, plus the
hundred or so links to busybox that turn it on.

-Bennett
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://lists.linuxfromscratch.org/pipermail/lfs-chat/attachments/20040818/76ff397a/attachment.sig>


More information about the lfs-chat mailing list