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
|
Home