On Thu, Sep 11, 2008 at 9:03 PM, Michael DeHaan <mdehaan@redhat.com> wrote:

I think trying to do this securely in the NFS realm is going to be
difficult if not impossible, indeed.

Maybe we just document it with scary blinking lights on the page that
(when using this feature) it's very easy to replace disk images without
hosts.allow, hosts.deny, /etc/exports, and/or iptables locked down to
specify what machines can write to that NFS share.   The vulnerability
is the option to replace someone's partition before they clone it to
lots of other machines, basically injecting new content.  However if
this is limited such that only machines in the datacenter can access
this content, then the problem becomes ensuring users can't access
/those/ machines.

Doing any sort of better locked down NFS install is a huge problem for
rw NFS, especially when the user is a CD -- we can't just stick the
password in the cloner image as the cloner image is public.

Other proposals welcome, perhaps ok for now.

Naturally since this NFS feature is not available until someone turns it
on and so configures their cloner images, we aren't exposing a
vulnerability in a place where users can't see that message about
limitations -- they'll know the implications when using the feature.

This may in fact be fine for most secured lab setups, just definitely
not something you'd want on an open college network.

--Michael


I was thinking of some setup with ssh and host keys, but any host key would need to be on the livecd image itself.  I can't think of a good way to secure this system, NFS or not.  I suppose it's okay if this feature is only practical inside of a secure lab setup though.