locked down knoppix
sjansen at buscaluz.org
Fri Nov 11 21:42:40 MST 2005
I've been on hiatus from the local lists so I didn't know about the
recent discussion until goozbach pointed it out to me. Thought you guys
might enjoy knowing a bit more as I found it was a pretty fun project to
Recently, we were asked to create a proof-of-concept bootable Linux CD
that would allow a certification candidate to connect to a single remote
server and nothing else. The CD would only be a used in professional,
proctored certification facilities. Any solution provided could not
depend on the testing facility making changes to their computers or
I decided to base the CD on the latest release of Knoppix. The system
was stripped down to not much more than Firefox, a window manager and
files required to boot. Firefox ran as a normal user. Ctrl-Alt-Backspace
was disabled. VT switching was disabled. For good measure, the getty's
were also disabled so there would be no VT's to switch to. The firewall
was configured to allow only ICMP, DHCP, and TCP on ports 80 and 443 to
a single IP address inside of BYU. (As an easter egg, all traffic was
filtered through a chain named SJANSEN.) Instead of using DNS, an entry
was added to /etc/hosts.
I was impressed by how easy it was to create the disc. As it turns out,
a Linux "guru" can create a secure solution very quickly. The
proof-of-concept was produced in less than 24 hours--most of which was
spent discovering and resolving strange Knoppix-isms during boot. My
disc, while frankly ugly and unpolished, was almost usable as-is.
Were I producing the real thing, I would have added several things.
First, I would have preferred allowing TCP on 443 only. At least some
research into the effect of proxies in the testing facility would have
been needed. I would have locked down the boot loader better. I would
have run the Web browser inside of a chroot. I would have made sure that
Magic Sys Request was disabled. I would have created a custom interface
on top of Gecko instead of trying to lock down Firefox. I would have
performed a full audit of the boot scripts. I probably would have
created a custom kernel with support for only input, video, network, and
the CD drive. No FAT, ext3, etc. support. Probably no USB mass storage
support. At that point, I think the biggest danger would have been
candidates with photographic memories or photographic equipment.
I don't know enough about Windows to evaluate the difficultly of
producing an equivalent solution. However, my gut tells me it would not
be nearly as easy or cheap to create such a safe testing environment.
There's a lot to be said for running in an environment that doesn't
include an instant messenger, an email client, or even a copy of telnet.
Stuart Jansen e-mail/jabber: sjansen at buscaluz.org
google talk: stuart.jansen at gmail.com
:0 # copy & paste for your convenience
/dev/null # /ignore sjansen!*@*
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://plug.org/pipermail/plug/attachments/20051111/dd938f41/attachment.bin
More information about the PLUG