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

[Michael South <msouth@xxxxxxxxxx>]

Picking up on some of your other points:

Yes, Xen documentation sucks big-time. For example, it's impossible to find 
what boot methods are available (pygrub, pvgrub, etc.), what works with what, 
and what's obsolete. Of course, saying "somebody ought to..." is a time-honored 
way of volunteering :) You up to it? Time, enthusiasm, and being able to work 
with people are more important than deep knowledge, IMHO.

Further hardening of dom0 is a really interesting idea. For example, is there 
really any need for a shell? Any need for any users who can do a 
general-purpose log-in? All we want is to start, stop, monitor, and configure 
domUs. Even grub has a lot of extra junk in it. Talking about what we want is 
appropriate for xen-users, methinks. Xen-dev can tackle hiw to implement.

What do folks think?

--
Michael South
msouth@xxxxxxxxxx

On May 11, 2011, at 16:45, Adrien Guillon <aj.guillon@xxxxxxxxx> wrote:

>> In this case, adding a shadow file will not actually increase security. The 
>> best it could do would be to provide "check the box" "warm and fuzzies" for 
>> people who do not understand shadow's purpose. As such, it would be a 
>> _false_ sense of security. This may be the case here; "if I have shadow 
>> files, then it's safe to expose the dom0 login to the bare internet."
> 
> I don't believe this, rather I believe that if any daemon has a
> problem at all... literally anything since it's globally readable...
> the hash can be exposed.  I think that the discussion started to go
> onto a tangent on security of management interfaces and all of these
> topics which are indeed important, but tangential.  The security of
> the system is now determined by the lowliest application, some defunct
> Perl script running as "nobody" can now expose a password hash.  Yes,
> as we discussed, we can isolate the network.  But I think you all have
> to see that even with it isolated, the problem is still there.
> 
> As evidenced by this thread, there is quite a bit of good information
> on "how Xen is meant to be used" which was not evident to me in the
> documentation that I read.  I think that a nice wiki page on "best
> practices" or "suggested setup" could convey to the rest of the world
> what you have taken the time to convey to me.  Heck, someone can
> probably write a nice article based on some of the ideas brought up in
> this thread.  This would do a lot for others who are looking at Xen as
> I was.
> 
> I still will not budge on the problems with /etc/passwd.  I understand
> the evidence and arguments presented.  However, the issue is that any
> user (I'm talking system users, not people here) can get access, even
> if it is on "the internal network".  We have discussed the need to
> separate a potentially insecure interface from the "big bad Internet",
> and I agree fully with this.  However, in my view there is still a
> problem.  It's like saying "yes, yes... if you ping the system it will
> email you the password... but we don't allow ping see, we put it on a
> separate isolated network where ping is not allowed... where do you
> see a problem?!"  I believe, personally, this is avoidance of a
> problem, and when it comes to open-source software I think problems
> should be confronted, that is why I am here.
> 
> Regarding updates, could it be that shifting XCP to a Debian-based
> distribution will help?  I admit I have some bias, since I prefer
> Debian-based distros (although I did have a fling with Gentoo for a
> few years, but it's over between us).  Should we, perhaps, make a
> concerted effort to adjust XCP to be a hardened distro rather than
> just a fork of something put out by Citrix?  This discussion likely
> belongs on the devel list, but I just wanted to put it out there.

_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users