Joseph you are exactly right documentation is definitely in need of
work in the case of XCP. Fortunately for the community the person who
is spearheading the effort is a really bright individual and in the
long run the documentation will get there.
On Mon, May 9, 2011 at 10:24 PM, Joseph Glanville
<joseph.glanville@xxxxxxxxxxxxxx> wrote:
> Hi,
>
> The points highlighted don't represent security risks if the dom0 is
> properly isolated on a secure management network.
> Following that, the only attack vector then available is exploitation
> of the hypervisor from untrusted guests. At which point UNIX
> permissions aren't worth much.
>
> However, the fact someone was to bring up the points signifies there
> is a lack of communication as to how XCP and systems like it are meant
> to be employed. Possibly some further documentation on XCP best
> practices is in order?
>
> Joseph.
>
> On 10 May 2011 11:44, Eduardo Bragatto <eduardo@xxxxxxxxxxxx> wrote:
>> On May 9, 2011, at 6:29 PM, Adrien Guillon wrote:
>>
>>> Security updates are common, and generally do not make major interface
>>> changes by design. I have no desire to update anything aside from
>>> receiving fixes for buffer overflows, or other exploits that are found
>>> in the wild. The system in question should be in production for
>>> several years, and security patches are inevitable during that period
>>> of time.
>>
>> In Xen's case I will have to disagree. If you're trying to build an HA
>> cluster, you need to make sure all your nodes have precisely the same dom0
>> if you want things like live migration to work properly.
>>
>> Besides disrupting one single system, problems caused by updates could
>> potentially harm the entire pool (how do you update all dom0 nodes to the
>> same software version at the same time and make sure nothing will try to be
>> "live migrated" from one node to another in the meanwhile?)
>>
>> The concern about buffer overflows is intrinsically related to security,
>> which is the next topic...
>>
>>> It likely took some effort to eliminate /etc/shadow in the first
>>> place, as this has been standard practice for a very long time. I
>>> will not debate the merits of storing hashes in /etc/passwd or
>>> /etc/shadow because that debate ended a very long time ago. Quite
>>> simply this distro has a major security flaw.
>>
>> As others have pointed out, dom0 is not supposed to be accessed by anybody
>> other than root. I would go further and say it's not supposed to be accessed
>> over any public network, such as the Internet or the wifi network you'd find
>> in a Starbucks.
>>
>> I believe the main idea is that you should isolate dom0 from the world in
>> all possible ways, so no matter what security flaws it might have, they will
>> never be exploited.
>>
>> Maybe they should make it explicit like: you should always run dom0 on a
>> private network, controlled and secured by VPNs or any other methods.
>>
>> Best regads,
>> Eduardo Bragatto
>>
>> _______________________________________________
>> 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
>
_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-users
|
Home