Hi
I agree strongly with this sentiment of "the documentation sucks".
Recently I have been doing my best and answer questions on the lists
and further my engagement in the Xen community and the next logical
step for me is to tackle the seemingly impossible task of
documentation. I think this applies more globally to Xen than to XCP -
none of the Xen.org projects are adaquately documented at this point
in time. Both user documentation and developer documentation is very
sketchy at the best of times, and what is there is usually quite
out-dated or is the left overs of a half baked research project that
was never integrated into the Xen mainline tree. It doesn't help that
the Xen community praises configuration over convention (not saying
this is a bad thing) as it makes documentation very difficult - mainly
because we advocate customizability over set configurations.
Documentation (for new users atleast) will be considerably easier when
dom0 kernels return to being available in most distributions.
On the hardening front I don't think any further hardening is required
if XCP is used exclusively as a virtualization appliance. If there is
no shell access other than physical maintance and all authentication
and authorization is handled via APIs that don't have the breadth of a
shell then attack vectors are minimal to start with. Though the kind
of hardening I would recommend is far from what was suggested in the
previous thread.
Multi-user style hardening of the root account, filesystem and config
files etc is not required. As partitioning the deamons up into
seperate users and groups is mostly superficial. As ultimately deamons
will have VMM access and thus compromising the dom0 OS isn't required
for most attacks to be considered effective. However it does have some
merit by being able to restrict the impact of a vuln in one deamon
from compromising other deamons.
I think at some point in time XCP will need to have a focus session
where these points can be discussed and a conclusion reached on what
lengths the XCP developers are willing to go to further harden XCP
without hindering feature and stability development.
Joseph.
On 12 May 2011 07:33, Michael South <msouth@xxxxxxxxxx> wrote:
> 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
>
--
Kind regards,
Joseph.
Founder | Director
Orion Virtualisation Solutions | www.orionvm.com.au | Phone: 1300 56
99 52 | Mobile: 0428 754 846
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home