Is Skolelinux safe?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
On the scandinavian linuxiskolen@skolelinux.no 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 linuxiskolen@skolelinux.no 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-----
Reply to: