-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On the scandinavian [EMAIL PROTECTED] mailinglist, the question ~ was raised of what is missing for Skolelinux to be considered safe to use.
It was pointed out[0] that...
~ 1) Sniffing is relatively easy
~ 1a) Sniffing is harder on a switched network
~ 1b) Some switches are unsafe: can be fooled into acting like a hub
~ 1c) It is difficult to figure out wether a switch is safe
~ 1d) Even switched networks can be easily abused by adding a hub
~ 1e) Sniffing + abuse of PHP sessions is as insecure as OpenMosix.
~ 2) NFS is accessible from any machine on the LAN
~ 2a) Using MAC address list of all known machines makes NFS safe
Sniffing - --------
I agree that switches are better than hubs. I compare it to whispering your credit card pin code instead of shouting it - which is still expressing it verbaly, just as thin client communication is still unencrypted on the wire. ALL coomunication, including all keys pressed on the keyboard.
I disagree that Sniffing is as insecure as OpenMosix (if anyone still considers OpenMosix safe for thin clients): Sniffing is passive - you need your sniffing device running until you capture a valid login+password or whatever secret you hope to steal. Only then (if what you captured was admin access) you have access to all files to manipulating applications to your liking. With OpenMosix each participating peer is trusted random pieces of applications directly - so given a clever device with knowledge of OpenMosix it can actively distort what applications run by others do to on the server. Switching is completely irrelevant here, as you are kindly handed the applications to crack if only you (are allowed to) volunteer as an OpenMosix node!
NFS security by MAC addresses - -----------------------------
A MAC address is a serial number hardcoded on each networking card, unique in the world. It is read by the Linux kernel nic driver and handed to the networking drivers. It is pretty trivial to sniff the network (yes, even a switched one), capture the MAC addresses of some approved machines, and later impose as them.
Secure thin client networking - -----------------------------
Below is some notes on real security, not "security by obscurity" (relying on X traffic not being widely abused) or relying on spoofable id (both MAC addresses, DNS names and IP numbers are relatively easily spoofed[1]). Lessdisks mentioned in the text is an alternative to LTSP, based on Debian (LTSP until the newly released 4.x is based on Redhat) and implemented almost purely with shell scripts: approx. 1 MB architecture independent code, reusing even the standard Debian kernels. I am currently working with the author on getting lessdisks into Debian officially.
~ 1) Kernel and base system is public knowledge by definition
~ 1a) Make sure thin clients can trust what is provided publicly[2], to avoid fake server handing out manipulated kernel or root file system.
~ 2) Encrypt all non-public communication.
~ 2a) Generate a random encryption key locally on the client[3].
~ 2b) Make sure private part of server keys are generated locally on the LAN[4].
~ 2b) Choose carefully the encryption ciphers, especially for low-end clients, instead of dropping it entirely[5].
~ 2c) Distribute public part of server keys safely to all clients, preferrably as part of base system, but only if base system is created and signed at the local LAN (as server keys must not be distributed globally).
~ 2d) Login securely, and tunnel X communication securely. With Lessdisks this is done by the script sdm using SSH. With lessdisks 4 (not yet ackaged for Debian) it seems to be also somehow possible (but only optional?) using SSH.
~ 2e) If access is needed from local client to personal files on server (e.g. when running some applications locally) do it securely. Lessdisks uses a Debian chroot so any Debian-supported secure filesystem can be used. Simplest to setup secure filesystems seems to be SFS and NFS-over-SSH[6].
~ - Jonas
[0] If you want recognition as provider of some of the above, then please pretty please post your valuable notes to *this* list instead of the nerwegian one. Let's have also non-scandinavic eyeballs on this important topic!
[1] LTSP identifies machines based on DNS (which in turn is based on DHCP and thus MAC addresses). Skolelinux thin clients has on top of that an access layer based on DNS
[2] Etherboot has recently added support for public-key signing: The nic ROM (or floppy) image includes the public key of, say, Skolelinux.no and checks that the kernel and initrd provided by the server has a matching public key.
[3] If client encryption key is provided with base system, then the key to decrypting your communication is in reality public!
[4] In the past, a generic Webmin key was distributed officially with the Debian package and used globally.
[5] On the nordegian [EMAIL PROTECTED] mailinglist was noted that use of SSH for thin clients was considered but refused severeal months ago due to processing constraints on low-end machines. I am unaware of the details, but possibly the tested systems did not by default use Blowfis: http://www.linuxjournal.com/article.php?sid=6602
[6] NFS-over-SSH is documented here: http://www.samag.com/documents/s=4072/sam0203d/sam0203d.htm
- -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/
~ - Enden er n�r: http://www.shibumi.org/eoti.htm -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFATQvtn7DbMsAkQLgRAtOqAJ9Fqf5xv0CNXo78T3H6HntTXtIn3wCfRxfg ar0VAHeId8OVI+YqmuQE+9k= =5yKj -----END PGP SIGNATURE-----
