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.
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.
| No, I just snfs mount the filesystems of my bastions on another box
| 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.
1. Your files are unencrypted on Lensman, and Sentry mounts
it with strong authentication and connection security. Lensman's
kernel can send out false versions of the files (from perhaps
/usr.old/, when the request comes from Sentry. Lensman can even offer
that up as being /usr. Sentry can't detect the deception, and your
tripwire runs, deceieved.
2. Your files are encrypted on Lensman, with local key
storage. If the attacker has root, then in theory this reduces to the
previous problem. Actually making this happen is more difficult.
3. Lensman and Sentry share a dual ported drive with a
hardware switch to control which side is readable. Lensman has a
small internal disk for swap & core dumps. The OS is stored on the
dual ported disk, read only regarding Lensman.
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.
"It is seldom that liberty of any kind is lost all at once."