> Simon J. Gerraty wrote:
> | In fact the next release of my user space NFS server also uses SSL for
> | transport and X.509 certs to authenticating mount requests - I've not
> | made this one publicly available yet though.
>
> I'm glad to hear that you're doing this, but I question if its
> the right model.
I did it because it was a very simple incremental change over the
previous version and addresses its main weakness. Namely that with
the current version, strongly authenticated TCP based mounts (via TIS
authserver) cannot be automatically re-established after a server
failure. This invariably leads to the client having to be rebooted.
Normally this is very rare but on a big firewall complex it happens
often enough to be anoying.
> Given the history of NFS security failures, and its explicit
> design as insecure, perhaps it would make more sense to build a secure
> file system on top of NFS, by using filesystem level crypto, and
> choosing to leave the transport insecure.
I think the steps already implemented in snfs address most of NFS's
problems. Transport level crypto certainly makes it more secure - and
makes it simple to export out over hostile nets without having to
worry about guessed file handles etc. But again the main reason for
the SSL transport was for X.509 cert based authentication of mount
requests - which can be automagic. And I already have all the
infrastructure to support it.
> | and run tripwire on them. This avoids the problems alluded to by mjr
> | I think, where tripwire can be fooled if the kernel or libc.so on the
> | box running tripwire have been tampered with.
>
> Lensman will be the NFS server, and Sentry the client.
> ...
> I think that only in case 3 do you get out of the 'Well, our
> all clever hacker really controls the kernel, and we're screwed'
> situation. Products like Decaf and SeOS may also help.
You are quite correct. That's what I get for typing without thinking
long enough...
--sjg
References:
|
|
