Andrew Brown wrote:
On Thu, Sep 11, 2008 at 1:22 PM, Michael DeHaan <mdehaan(a)redhat.com
<mailto:mdehaan@redhat.com>> wrote:
Excellent. Glad to see this is still going on. I've added this to
"/contrib" in Cobbler's git and will go about testing this shortly (as
in next thing I do here).
Yes, moving to something a bit smarter than dd would be good. If we
continue to go down that route, likely we would want to see
partimage-ng
packaged for fedora as well -- so that we'd be able to host the cloner
image up on Fedora's infrastructure so other people wouldn't have to
build it (having all things part of Fedora is a requirement). Does
anyone else have comments/experience on partimage vs partimage-ng?
After I get testing together (assuming it all works), I'll add some
instructions to the Wiki of how to use this in conjunction with
cobbler
commands. I have some spare machines here so I'm interested to
see how
it all works out. That might warrant making some commands to make
that easier, TBD.
I think the "newkoan" part of the config is unneccessary and left over
from koan's live image, so I'll probably clean that up. I'm guessing
we can also probably pare-down the package set some and disable a few
extra services, though that's not major.
Anyhow, very cool.
--Michael
Woah, I got your emails all out of order. Just got this one somehow.
Anyways, the NFS export /is/ running as no_root_squash. It didn't
occur to me earlier, but yeah, that could be an issue. The script
could easily run as another user (other than root), but then it
wouldn't have permission to write to the hard drive device. I'm not
sure of a good way to solve that.
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