| |
|
 |
|
 |
|
|
|
| |
|
|
xen-devel
Re: [Xen-devel] Re: Module loading in unpriveledged domains
I don't think the original poster truly understands how xen works,
otherwise they wouldn't have asked about module loading and it's
security implications in xen.
This isn't another vserver or uml project. It doesn't matter what you do
with the individual guest kernels. The fact of the matter is that they
have no authority (unless they are a privileged domain) to affect xen's
security.
Now bugs in xens security enforcement methods *might* be exploitable,
but from what I can see this is a fairly easy area to audit. The use of
event channels makes it tougher than usual for a unprived domain to
break into a backend driver domain. That of course would be easilly
audited as well.
With the page wiping in xen 2.0.x now, I don't see how a domain could
exploit anything in xen with used memory that is handed back to xen from
drivers.
I don't know of any areas of xen that attempt to execute code from
allocated memory blocks that a domain hands to xen directly. I can't
imagine any other method to comprimise the xen hypervisor. Anyone else
as or more familiar with the main hypervisor kernel aware of, or can
image ways to bust through it's security?
my 0.2 cents of admittedly limited understanding of xen'd security and
methods...
Brian
On Tue, 2004-11-23 at 18:43 +0200, Nuutti Kotivuori wrote:
> David Hopwood wrote:
> > True, unless there are bugs that cause different behaviour depending
> > on whether a module is compiled-in or loaded (such as
> > <http://lists.jammed.com/linux-security-module/2003/12/0012.html>).
> > Nevertheless enabling loadable modules may allow a greater
> > proportion of script kiddies to be capable of exploiting any given
> > bug.
> >
> > This is all the same as in standard Linux, so perhaps I should have
> > said: enable loadable modules iff you would do so in standard Linux.
>
> That's a bit of an odd comment I think.
>
> Enabling module loading has security implications for the actual Linux
> system being exploited - eg. either the physical machine in a
> standalone case, or a Xen guest virtual machine.
>
> But the original question was not about the security of that machine,
> but about the possibility of escalation of that exploin into other
> Xen guests or the domain 0 on the same physical machine.
>
> So for the escalation case, in both cases we are talking about a fully
> exploited Xen guest virtual machine trying to break out of Xen
> separation - and in that case, I don't see how module loading makes
> any difference.
>
> So the complete answer would be - yes, module loading in unpriviledged
> domains has security implications in unpriviledged domains as much as
> it has on standard Linux machines - but no, module loading in
> unpriviledged domains has no security implications with regard to
> other machines running on the same host, aside from those normally
> incurred by Xen.
>
> And I think the latter part of the answer was what the original poster
> intended.
>
> -- Naked
>
>
>
> -------------------------------------------------------
> SF email is sponsored by - The IT Product Guide
> Read honest & candid reviews on hundreds of IT Products from real users.
> Discover which products truly live up to the hype. Start reading now.
> http://productguide.itmanagersjournal.com/
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/xen-devel
--
-------------------------------------------------------
SF email is sponsored by - The IT Product Guide
Read honest & candid reviews on hundreds of IT Products from real users.
Discover which products truly live up to the hype. Start reading now.
http://productguide.itmanagersjournal.com/
_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxxx
https://lists.sourceforge.net/lists/listinfo/xen-devel
|
|
|
| |
|
Home