***I'm reposting my post again with better spacing.***
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
Sure it can. It is the "trusted Domain" after all. However, the reverse
isn't true. A DomU cannot access anything running on the Dom0 without
going via a network.
I think the bottom line is that if you want to use your Dom0 in the
traditional sense (as in, use it like a "real" linux environment), then
maybe XCP isn't for you. You shouldn't really need to log into the shell
of XCP at all. If you are finding that you do, then maybe you should
just install Xen with a CentOS Dom0 and work from there. If you don't
log into the shell, then you won't be executing any binaries yourself,
hense nothing can be exploited. It goes back to the Washing Machine
concept. If you don't plug your laptop up to the RS232 terminal of your
TV/Washing Machine/Microwave/Kitchen Sink, then it can't be hacked.
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.
You should nevel place a server management interface on a VLAN that is
accessable from the internet. If you do, at least firewall the box!
In my usage scenario, this machine is going
onto the real Internet, no firewalls, no nothing.
This comment is alarming. Usually, the phrases "real Internet" and "no
firewalls" don't go together is a huge cause for concern. I don't think
having no /etc/shadow is your biggest problem....
If you are scanning for a PCI DSS compliant environment, I suggest you
switch off your network, go back to the drawing board, and re-evaluate
your network topology.
I was completely
unaware that such assumptions of a friendly world were in place.
For a management interface, a friendly world is always assumed. Just
having a password isn't enough security. You shouldn't give outside
users access to a login prompt that they are able to log in as root with
(that's what VPNs are for). Also, if you're doing a PCI DSS audit, any
VPN used must be 2-factor, but this is OT.
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
You don't log into the shell of an appliance, but just access its "Front
End" features. In the case of XCP, that's just using the API.
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.
Yes, updates using yum would be useful, but would require specific
repos. Remember, while XCP is Linux based, this doesn't means it's using
an environment that is 100% compatible with its upstream provider
(CentOS/RHEL I believe). Generally, to update XCP, you should just use
the downloads from xen.org. Remember, if you don't access the shell,
nothing will be exploited.
You shouldn't really have the need to run your security scanner on the
Dom0 of XCP. That's just breaks the methodology of XCP being an
appliance. If you really want somthing to test with XCP, track and
exploit the API used.
I hope my comments help
Oh and just to re-iterate, please firewall that box!
Xen-users mailing list