On Wed, May 11, 2011 at 7:47 AM, Adrien Guillon <aj.guillon@xxxxxxxxx> wrote:
> Now, I am not intimately familiar with Xen, but are you telling me
> that there is zero potential for dom0 to interact with any other
> running VM? It cannot, say, read partitions allocated with LVM for
> virtual machines? Cannot copy file that act as storage for the VMs?
> Of course, the kernel cannot be patched in /boot either and the system
> rebooted? None of these possibilities exist because of some unique
> properties of dom0? I'm no Xen expert, so can someone can fill in
> these blanks?
dom0 can access domU's storage.
The point that was given by others is NOT that dom0 can't acess domU's
storage. Rather, access to XCP dom0 is already LIMITED in that:
- it should be on a private, management network
- it does not run any unnecessary services
- most admin access should be done via the web interface.
with that setup, unpriviledged user common in normal Linux distros
(e.g. httpd user, or some other non-root user) will likely NOT be able
to access arbitrary part of dom0's filesystem anyway, so arguably
filesystem permission is not as critical as it is on normal Linux
distro.
>
> Another argument that has come up was that the network card on dom0 is
> on a trusted network, now this is news to me. None of my research
> showed this, and certainly for an assumption so critically important
> it should be in enormous block letters when you configure XCP in case
> you missed it like I did. In my usage scenario, this machine is going
> onto the real Internet, no firewalls, no nothing. I was completely
> unaware that such assumptions of a friendly world were in place.
Are you saying that (for example) when you have a Cisco switch/router
you'll put the management interface in public network? Seriously?
The best practice for management interface (whether it's XCP, router,
or server ILO) is to put it in private network, separate from normal
traffic. In practice, this can be just a separate vlan.
>
> Participants of this thread have also thrown around the idea that XCP
> is an "appliance" not a distribution. Can someone give me a
> legitimate technical definition of an appliance? My search for
> "distribution vs. appliance" on Google brings up a washing machine
> place.
The most relevant part from wikipedia
http://en.wikipedia.org/wiki/Computer_appliance
"
These devices became known as "appliances" because of their similarity
to home appliances, which are generally "closed and sealed" – not
serviceable by the owner. In computer appliances the hardware is also
usually sealed and not repairable or upgradeable by the user.
"
in XCP case, the "not repairable or upgradeable" part would refer to
the fact that you should not perform any manual/additional
customization that you usually use on normal distro, like:
- install additional package
- use any standard distro package management command (like yum)
- add system user using "useradd" or similar
While some appliance (example: Linux-based Brocade SAN switches, or
Allot bandwitdh management appliance) might allow root access via ssh
directly, using it to modify the system directly is not supported and
can void your warranty/support.
>
> My second point regarded updates. It was suggested that the way to
> deal with this is to reinstall. In a production environment this is
> often not acceptable. I believe it would be worth the effort to find
> a way to send out security updates without affecting Xen itself.
That would be useful, true. But like I said earlier implementing it is
not as easy at it sounds.
So to sum it up:
- Some of your concerns are valid, although I disagree on the degree
of importance
- XCP has taken least-effort path to make the system secure-enough
- you can contribute to XCP development since it's open source. AFAIK
the best way to do so by joining xen-devel or xen-api list and sumbit
your improvements there
- If you only want a feature/bug fix added without implementing it
yourself, then AFAIK the best way to do that is to get a Citrix
XenServer support and file a feature request.
Again, xen-users is mostly where Xen users (not developers) hang
around, so even if there's a big flame war here, there's no guarantee
that it would catch a developer's attention :)
--
Fajar
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home