My two cents... (I'm not replying to any specific points, so have elided
original msgs.)
Xen is _not_ intended to do the same thing as VMware, Parallels, or other
virtualization utilities running on a desktop or laptop. It doesn't extend a
"main" OS with extra capabilities. Instead, think of it as a management port on
a blade server box, letting you move CPU chips, memory DIMMs, and disk cables
between the blades. The hypervisor is the blade backplane. Dom0 only has two
purposes in life: 1) run the lowest levels of the hardware drivers, 2) update
the "firmware" binaries and configuration. Everything else, such as compilers
to create the binaries, user management and authentication services, mail, web,
file sharing, NTP, and _especially_ publicly accessible login/shells, should go
on the "blades"--the domU's.
You could also think of the hypervisor/dom0 as a very weird router. Exposing
this to the public makes operations people nervous for the same reasons that
exposing a Cisco box's management interface would.
A very common model for this would be:
--
Michael South
msouth@xxxxxxxxxx
On May 10, 2011, at 23:39, Jonathan Tripathy <jonnyt@xxxxxxxxxxx> wrote:
> ***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
>> 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
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home