Re: Is Skolelinux safe?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andreas Schuldei wrote:
| * Jonas Smedegaard (dr@jones.dk) [040309 02:36]:
|
|>~ 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].
|
|
| both 2d and 2e are rather fragile tunnels. ssh is not meant to be
| used for this kind of job. ipsec is the right tool for the job
My main points was those in the initial sentences: Do both login and
file access securely. With that I meant do it with the use of encryption.
I agree with you that IPsec, Kerberos and AFS are (probably - I have no
actual experience with either of them) more robust on the longer run.
However, I understood the question as being "how little effort can we
get away with putting into this in order to claim to be adequately
secure?", and in my understanding (security) and experience (stability,
resources) SSH is adequate.
A major point is using SSH is we need no custom built kernel! We can use
the official Debian kernels, and only add extra logic to an initrd
supporting NFS boot (I have a working script and the Lessdisks
maintainer is working omn another more modular approach partly inspired
by mine.
Please be more specific as to why (or if) you think that SSH should be
avoided for tunneling - also on a shorter term.
| and is in the debian kernel for some time.
...but as kernel patches, not readily built modules.
with that one can
| tunnel traffic nicely. cyphers like blowfish or AES can be used
| even on lowend machines without performance hit.
Do I understand you correctly that you are talking "encryption"
generally here, which (possibly) goes for both IPsec and SSH?
| if the servers need to encrypt larger ammounts of data (high
| traffic volume, many clients) it can help a lot to utilize
| hardware random number generators. sometimes those are integrated
| into the chipset and are highly costeffectiv that way.
Good point!
| generally servers are much more vulnerable when RPC and the
| portmapper are used.
True. On the other hand NFS is a stable technology ("stable" as in
widely exercised and not in rapid development).
What SFS and NFS-over-SSH does is using NFS on the localhost.
NFS-over-SSH even uses fixed port numbers to avoid the need for the
portmapper (I don't remember if that trick is usable with SFS as well,
but probably). In effect, you need not exposing the ill-rumored RPC and
portmapper to the network.
I certainly agree that your proposals are interesting as a long term
goal, but please (re)consider SSH-based tools for now.
~ - Jonas
P.S.
No need to Cc me, I am subscribed to the list :-)
- --
* 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
iD8DBQFATcyln7DbMsAkQLgRAmHfAKCbDGMu+9rBhUG14+vrM7Hts4MXxACggVfO
riqogi9ioyVmiijWFfPmnwc=
=Fy/U
-----END PGP SIGNATURE-----
Reply to: