Re: [Xen-users] XCP: Insecure Distro ?

[Jonathan Tripathy <jonnyt@xxxxxxxxxxx>]

> 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?
>    
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
> place.
>    
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
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users