If you run any Perl scripts, or anything that can usefully be 'nobody', on
dom0, then you're doing it wrong. Create a domU and run it there.
Doing it the other way around is like using the wooden part of a hammer to
pound nails, then complaining that it's a lousy tool. If your proposed
application _really_ needs to hit those nails with a long skinny thing, then
use a differemt tool, like a lead pipe. But try to keep an open mind--you're
going against the collected wisdom of lot of people's experience.
That said, it's your (and your employer's) neck. If you really want a
full-fledged "main OS" with some secondary VMs slotted in, you might want to
look at KVM. It provides an easy way to use QEMU to do that. Most of the
popular distros imclude KVM packages.
--
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