For those of you who might be interested, Karl Fogel has a great book
called "Producing Open Source Software", and a potentially relevant
section can be found here:
I brought up two issues regarding XCP. First, is that /etc/passwd has
the actual password hash stored within. I have read arguments in this
thread to the effect that "it doesn't matter because dom0 is single
user". I'm not sure what, precisely is meant by "single user" in this
context. "Single user" to me normally refers to an init level where
the system has networking disabled, and the system is undergoing
maintenance with an admin standing in a room typing away at a local
terminal. I doubt this is what is meant, instead I believe you mean
that "only one user should have access".
In this matter, and those familiar with Linux user philosophy can skip
this, the root account does more than offer a user access to the
system. The root account is the owner of executables, the custodian
of the kernel, and master of the machine. This root account is quite
special, and you will notice that very few programs are allowed to run
as root. Many programs will start as root, and will drop down to a
non-root system user with fewer privileges as quickly as possible.
This is done so that in the event one of these programs is compromised
it can do limited damage. In the context of XCP, any compromised (or
misconfigured) application can now read the password hashes from
/etc/passwd. This discussion has refuted that even this is not a big
deal, because dom0 has limited privileges.
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
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.
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
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.
I hope that this discussion can be helpful.
On Tue, May 10, 2011 at 7:11 PM, <admin@xxxxxxxxxxx> wrote:
> You are referring to a “no-no” that refers to multi user situations. XCP’s
> dom0 is a single user (root) environment, so you don’t have to worry about
> hardening the security in the same ways that you would in a multi user Unix
> SSH environment. In the case of XCP’s dom0, the passwd file is only
> “vulnerable” if you are already logged into the dom0 as root. And if you
> are already logged in as root, you would not need to worry about the passwd
> -----Original Message-----
> From: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
> [mailto:xen-users-bounces@xxxxxxxxxxxxxxxxxxx] On Behalf Of A Cold Penguin
> Sent: Tuesday, May 10, 2011 2:16 AM
> To: xen-users@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Xen-users] XCP: Insecure Distro ?
>> The points highlighted don't represent security risks if the dom0 is
>> properly isolated on a secure management network.
> Unfortunately there are some situations where even having an air-gap between
> networks, is not considered secure enough.
> Having the password hashes in world-readable files is basically a no-no, and
> would mean that this product could not go into production use.
> Basically this appears to be a relaxation in security against the 'norm', if
> this is only required due to keeping different pool members in sync,
> I think that investigation should be made into an alternative method of
> synchronising the members.
> Xen-users mailing list
Xen-users mailing list