Xen users - Nov 2008 - malicious paravirtualized guests: security and isolation

Hi,

I have a question about isolation and security guarantees Xen provides, if
any, in cases when domU guests are not completely trusted, that is, can be
malicious. Right now I am specifically interested in the scenario where all
guests are paravirtualized, but HVM case is of some interest too.

Say, I want to let my users run their own guests on a Xen host that I own.
Users will bring their own disk images. I don''t completely trust my
users.
Does the use of Xen guarantees that malicious guests will be unable to harm
other guests or the entire host in any way (for example, kill the entire
host)? It is interesting to know both what is guaranteed in theory (that is,
if Xen and dom0 work as designed) and how things go in practice.

If I disallow users to use their kernels, that is, if I run guests with my
own kernel(s) only, will that improve the situation? How about loadable
kernel modules? If I allow Linux guests to load their custom kernel modules,
will that nullify the effect of using trusted kernels?

I currently use Xen 3.1.4, if that matters.

Thank you very much in advance,
Vasiliy


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Hi,

Am I asking stupid questions or is this area a complete mystery? Any
pointers to existing sources of information are greatly appreciated. I spent
several days searching Xen documentation and googling but could not find
anything definitive.

Thank you,
Vasiliy

On Thu, Nov 6, 2008 at 4:15 PM, Vasiliy Baranov
<vasiliy.baranov@gmail.com>wrote:
> Hi,
>
> I have a question about isolation and security guarantees Xen provides, if
> any, in cases when domU guests are not completely trusted, that is, can be
> malicious. Right now I am specifically interested in the scenario where all
> guests are paravirtualized, but HVM case is of some interest too.
>
> Say, I want to let my users run their own guests on a Xen host that I own.
> Users will bring their own disk images. I don''t completely trust
my users.
> Does the use of Xen guarantees that malicious guests will be unable to harm
> other guests or the entire host in any way (for example, kill the entire
> host)? It is interesting to know both what is guaranteed in theory (that
is,
> if Xen and dom0 work as designed) and how things go in practice.
>
> If I disallow users to use their kernels, that is, if I run guests with my
> own kernel(s) only, will that improve the situation? How about loadable
> kernel modules? If I allow Linux guests to load their custom kernel
modules,
> will that nullify the effect of using trusted kernels?
>
> I currently use Xen 3.1.4, if that matters.
>
> Thank you very much in advance,
> Vasiliy
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, Nov 11, 2008 at 9:35 AM, Vasiliy Baranov
<vasiliy.baranov@gmail.com> wrote:
>> I have a question about isolation and security guarantees Xen provides,
if any, in cases when domU >> guests are not completely trusted, that is,
can be malicious. Right now I am specifically interested in >> the
scenario where all guests are paravirtualized, but HVM case is of some interest
too.
>> Say, I want to let my users run their own guests on a Xen host that I
own. Users will bring their own >> disk images. I don''t
completely trust my users. Does the use of Xen guarantees that malicious
>> guests will be unable to harm other guests or the entire host in any
way (for example, kill the entire >> host)? It is interesting to know both
what is guaranteed in theory (that is, if Xen and dom0 work as >> 
designed) and how things go in practice.
>> If I disallow users to use their kernels, that is, if I run guests with
my own kernel(s) only, will that
>> improve the situation? How about loadable kernel modules? If I allow
Linux guests to load their
>> custom kernel modules, will that nullify the effect of using trusted
kernels?
>> I currently use Xen 3.1.4, if that matters.
>
> Am I asking stupid questions or is this area a complete mystery? Any
> pointers to existing sources of information are greatly appreciated. I
spent
> several days searching Xen documentation and googling but could not find
> anything definitive.

I think it is a good question. Have you spent any time searching through the
xen mailing lists, in particular xen-devel might have some information. A good
way to search is using xen.markmail.org.

The xen developers (xen-devel) might also have some more insight for you.

There are probably some users out there in your situation, but the conventional
wisdom is that isolation and the security of it is very similar to
that of computers
on a network.

White hat hackers have been able to find various tricky ways to break out of
the isolation that xen provides, but I haven''t heard of any exploits
that have
been taken advantage of in practice.
http://theinvisiblethings.blogspot.com/2008/07/0wning-xen-in-vegas.html
http://xen.markmail.org/search/?q=Rutkowska

Hope that helps.

Cheers,
Todd

-- 
Todd Deshane
http://todddeshane.net
http://runningxen.com

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

I am trying to move a xen vm from one LV to another LV.

I know I can copy the current LV by shutting down the xen vm and doing this
command...

dd if=/dev/VolGroup00/LogVol00 of=/root/wdcdns1.img

How do I at this point mount the image file locally so I can verify its contents
or make changes?

Thanks for any help!

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Chris Edwards wrote:
> I am trying to move a xen vm from one LV to another LV.
> 
> I know I can copy the current LV by shutting down the xen vm and doing this
command...
> 
> dd if=/dev/VolGroup00/LogVol00 of=/root/wdcdns1.img
> 
> How do I at this point mount the image file locally so I can verify its
contents or make changes?
> 
Maybe this is what you want.

http://www.centos.org/docs/5/html/Virtualization-en-US/ch-virt-accessing-data.html

Vu

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, Nov 11, 2008 at 5:52 PM, Todd Deshane <deshantm@gmail.com> wrote:
> On Tue, Nov 11, 2008 at 9:35 AM, Vasiliy Baranov
> <vasiliy.baranov@gmail.com> wrote:
> >> I have a question about isolation and security guarantees Xen
provides,
> if any, in cases when domU >> guests are not completely trusted, that
is,
> can be malicious. Right now I am specifically interested in >> the
scenario
> where all guests are paravirtualized, but HVM case is of some interest too.
>
> >> Say, I want to let my users run their own guests on a Xen host
that I
> own. Users will bring their own >> disk images. I don''t
completely trust my
> users. Does the use of Xen guarantees that malicious
> >> guests will be unable to harm other guests or the entire host in
any way
> (for example, kill the entire >> host)? It is interesting to know
both what
> is guaranteed in theory (that is, if Xen and dom0 work as >> 
designed) and
> how things go in practice.
>
> >> If I disallow users to use their kernels, that is, if I run guests
with
> my own kernel(s) only, will that
> >> improve the situation? How about loadable kernel modules? If I
allow
> Linux guests to load their
> >> custom kernel modules, will that nullify the effect of using
trusted
> kernels?
>
> >> I currently use Xen 3.1.4, if that matters.
>
> >
> > Am I asking stupid questions or is this area a complete mystery? Any
> > pointers to existing sources of information are greatly appreciated. I
> spent
> > several days searching Xen documentation and googling but could not
find
> > anything definitive.
>
>
> I think it is a good question. Have you spent any time searching through
> the
> xen mailing lists, in particular xen-devel might have some information. A
> good
> way to search is using xen.markmail.org.

First of all, thank you for replying, Yes, I searched these lists. I''ll
try
once more.

>
>
> The xen developers (xen-devel) might also have some more insight for you.

OK, I''ll try.

>
>
> There are probably some users out there in your situation, but the
> conventional
> wisdom is that isolation and the security of it is very similar to
> that of computers
> on a network.

Is a side note, perhaps I was not clear but the question is not about
network security. It is about the safety of the domU <-> hypervisor
interface and the safety of running guests on the same hardware as the
hypervisor, from the point of view of protection from untrusted guests.

>
>
> White hat hackers have been able to find various tricky ways to break out
> of
> the isolation that xen provides, but I haven''t heard of any
exploits that
> have
> been taken advantage of in practice.
> http://theinvisiblethings.blogspot.com/2008/07/0wning-xen-in-vegas.html
> http://xen.markmail.org/search/?q=Rutkowska
>
> Hope that helps.
>
> Cheers,
> Todd
>
Thanks again,
Vasiliy


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, Nov 11, 2008 at 6:05 PM, George Lenzer
<george.lenzer@cpl.org>wrote:
> Vasiliy,
>
> No, it''s not a stupid question, I think it''s just that at
this point not
> many Xen users are thinking about this aspect of
> paravirtualization/hypervisor.  Personally, I think hypervisor is a much
> higher risk than paravirtualization because of the possibility of malicious
> code making it into a Xen hypervisor (provided by a third party).  Given
> that Domain0 is sitting atop the Xen hypervisor purely for management
> purposes, I believe (but cannot say with any authority) that there is a
> possibility that there are things it can''t see happening at the
hypervisor
> level.  Also given the different nature of an HVM Xen implementation using
> the hardware directly, I think it might be possible for an attacker to do a
> lot more damage than just Xen on an old x86 with only PV domains.  But this
> is all rampant speculation by a complete amateur with no coding background.
>
> As far as your questions about letting users run their own VM guests, I
> don''t think they can kill the entire host as long as you limit the
system
> resources under their control.
>
Good point. Thank you.

> That isn''t to say they won''t be able to impact the
performance of other
> guests to some extent, but it would only be within the controlled
> limitations you set for a particular domain.  I can only take it on faith
> that the isolation between the guests is pretty opaque.  That is what the
> Xen architecture is supposed to provide.  I don''t see any way for
> unprivileged guests to be able to directly access areas of memory on the
> system or CPU registers that are outside of their allocation.  That
doesn''t
> mean it''s impossible.  Personally, I think the biggest area of
concern is
> the virtual networking that happens between the guests.  If it''s
not done
> with enough foresight it could allow an old fashioned host to host network
> password attack to be possible.
>
OK. In my case I think some neat stuff in my dom0 is going to take care of
virtual networking security.

>
> With the kernels and modules, I think that it would only be wise for you to
> restrict them to the kernel you provide.
>
Why? Why it matters (if Xen is designed to provide isolation anyways)?

> Building modules for them might be a bit tricky and unmanageable, but not
> impossible.
>
Sure. :)

> Regarding the security of running their own modules, it I still believe
> that they would not be able to cross the boundaries of their domain into
> other domains via this route.  Unless something is seriously broken in the
> Xen paravirtualization model, when they are in unprivileged domains, they
> can''t access anything that Domain0/Xen microkernel
doesn''t allow.
>
I am far from being Linux expert but I thought a module can override
anything in the kernel. Am I wrong? If am not wrong, why disallowing custom
kernels while still allowing custom modules can be different from allowing
custom kernels?

> Hope this uninformed guessing helps a little and maybe gets more people
> talking, if only to tell me what a fool I am.  ;)
>
> George
>
Thank you very much,
Vasiliy

>
> ----- Original Message -----
> From: "Vasiliy Baranov" <vasiliy.baranov@gmail.com>
> To: xen-users@lists.xensource.com
> Sent: Tuesday, November 11, 2008 9:35:25 AM (GMT-0500) America/New_York
> Subject: [Xen-users] Re: malicious paravirtualized guests: security and
> isolation
>
> Hi,
>
> Am I asking stupid questions or is this area a complete mystery? Any
> pointers to existing sources of information are greatly appreciated. I
spent
> several days searching Xen documentation and googling but could not find
> anything definitive.
>
> Thank you,
> Vasiliy
>
> On Thu, Nov 6, 2008 at 4:15 PM, Vasiliy Baranov
<vasiliy.baranov@gmail.com
> > wrote:
>
>> Hi,
>>
>> I have a question about isolation and security guarantees Xen provides,
if
>> any, in cases when domU guests are not completely trusted, that is, can
be
>> malicious. Right now I am specifically interested in the scenario where
all
>> guests are paravirtualized, but HVM case is of some interest too.
>>
>> Say, I want to let my users run their own guests on a Xen host that I
own.
>> Users will bring their own disk images. I don''t completely
trust my users.
>> Does the use of Xen guarantees that malicious guests will be unable to
harm
>> other guests or the entire host in any way (for example, kill the
entire
>> host)? It is interesting to know both what is guaranteed in theory
(that is,
>> if Xen and dom0 work as designed) and how things go in practice.
>>
>> If I disallow users to use their kernels, that is, if I run guests with
my
>> own kernel(s) only, will that improve the situation? How about loadable
>> kernel modules? If I allow Linux guests to load their custom kernel
modules,
>> will that nullify the effect of using trusted kernels?
>>
>> I currently use Xen 3.1.4, if that matters.
>>
>> Thank you very much in advance,
>> Vasiliy
>>
>
>

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

Am I making the LV image correctly by doing a...

dd if=/dev/VolGroup00/LogVol00 of=/root/wdcdns1.img

---

Chris Edwards
Smartech Corp.
Div. of AirNet Group
http://www.airnetgroup.com
http://www.smartechcorp.net
cedwards@smartechcorp.net
P:  423-664-7678 x114
C:  423-593-6964
F:  423-664-7680


-----Original Message-----
From: Vu Pham [mailto:vu@sivell.com] 
Sent: Tuesday, November 11, 2008 10:07 AM
To: Chris Edwards
Cc: xen-users@lists.xensource.com
Subject: Re: [Xen-users] Mounting Xen Image

Chris Edwards wrote:
> I am trying to move a xen vm from one LV to another LV.
> 
> I know I can copy the current LV by shutting down the xen vm and doing this
command...
> 
> dd if=/dev/VolGroup00/LogVol00 of=/root/wdcdns1.img
> 
> How do I at this point mount the image file locally so I can verify its
contents or make changes?
> 
Maybe this is what you want.

http://www.centos.org/docs/5/html/Virtualization-en-US/ch-virt-accessing-data.html

Vu

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, Nov 11, 2008 at 14:35, Vasiliy Baranov
<vasiliy.baranov@gmail.com> wrote:
> Hi,
>
> Am I asking stupid questions or is this area a complete mystery? Any
> pointers to existing sources of information are greatly appreciated. I
spent
> several days searching Xen documentation and googling but could not find
> anything definitive.
Ok, you have to know what to look for, but dropping "theo
virtualisation" into Google got:

http://kerneltrap.org/OpenBSD/Virtualization_Security
https://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-virtualisation.html

You may find them food for thought ;)

-- 
                 Please keep list traffic on the list.

Rob MacGregor
      Whoever fights monsters should see to it that in the process he
        doesn''t become a monster.                  Friedrich Nietzsche

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, Nov 11, 2008 at 5:40 PM, Rob MacGregor <rob.macgregor@gmail.com>
wrote:
> On Tue, Nov 11, 2008 at 14:35, Vasiliy Baranov
> <vasiliy.baranov@gmail.com> wrote:
>> Hi,
>>
>> Am I asking stupid questions or is this area a complete mystery? Any
>> pointers to existing sources of information are greatly appreciated. I
spent
>> several days searching Xen documentation and googling but could not
find
>> anything definitive.
>
> Ok, you have to know what to look for, but dropping "theo
> virtualisation" into Google got:
>
> http://kerneltrap.org/OpenBSD/Virtualization_Security
>
https://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-virtualisation.html
>
> You may find them food for thought ;)
>
here is another article that takes an interesting look at security and
virtualization:
http://www.usenix.org/publications/login/2008-10/openpdfs/musings.pdf


-- 
Todd Deshane
http://todddeshane.net
http://runningxen.com

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> 	Hi,
> 
> 	I have a question about isolation and security guarantees Xen
> provides, if any, in cases when domU guests are not completely
trusted,
> that is, can be malicious. Right now I am specifically interested in
the
> scenario where all guests are paravirtualized, but HVM case is of some
> interest too.
> 
> 	Say, I want to let my users run their own guests on a Xen host
that
> I own. Users will bring their own disk images. I don''t completely
trust my
> users. Does the use of Xen guarantees that malicious guests will be
unable
> to harm other guests or the entire host in any way (for example, kill
the
> entire host)? It is interesting to know both what is guaranteed in
theory
> (that is, if Xen and dom0 work as designed) and how things go in
practice.
> 
> 	If I disallow users to use their kernels, that is, if I run
guests
> with my own kernel(s) only, will that improve the situation? How about
> loadable kernel modules? If I allow Linux guests to load their custom
> kernel modules, will that nullify the effect of using trusted kernels?
> 
> 	I currently use Xen 3.1.4, if that matters.
> 
When developing the Windows GPLPV drivers I crashed my Dom0 (and
therefore all DomU''s) on a few occasions. That was under 3.0.3, 3.0.4,
and possibly some early 3.1.x versions of Xen. As crashing was the exact
opposite of what I was trying to do, I didn''t pursue it, but obviously
it has been possible in the past to cause a crash by doing something
wrong in the PV side of things.

Is there a limit on the amount of data you can write to the xenstore?
Overflowing some limit in xenstore could be one method of causing a
crash.

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, 2008-11-11 at 22:40 +0000, Rob MacGregor wrote:
> Ok, you have to know what to look for, but dropping "theo
> virtualisation" into Google got:
> 
> http://kerneltrap.org/OpenBSD/Virtualization_Security
>
https://www.c0t0d0s0.org/archives/3651-Theo-de-Raadt-about-virtualisation.html
> 
> You may find them food for thought ;)
The premise that "All software has bugs, the hypervisor is software,
therefore the hypervisor has bugs" is valid. But not all bugs open holes
that can be exploited.

I (for one) like the fact that Theo is paranoid, his work has provided
many with needed security and good user experiences. However, you have
to take some things with a grain of salt. He anticipates and describes,
not documents a negative. But that''s how research begins.

On the other side, one really does need to consider the possible scope
of damages should the worst happen. With a conventional setup, a
privilege issue in the kernel means only needing to patch and audit
servers running that  version.

A vulnerability in the HV would multiply that * the # of guests + dom-0
per physical server. So in essence, using Xen gives you 1 * the number
of physical servers more to audit or restore in the worst case. I agree
that the potential risk is greater, but I think it gets blown out of
proportion by the media.

Another CVE like the vmsplice hole in Linux could ruin your day just as
badly, if not worse. Or the Debian SSH keygen issue that went undetected
for years. I agree that examining the HV for potential holes is needed
work, but I think many focus on it just to ride the hype.

Its an interesting discussion, nonetheless. I''ve been running Xen since
2.0.7, I''ve never had to panic. Its interesting (and yeah, a little
scary) to wait and see what if anything so many more eyes looking will
turn up.

Cheers,
--Tim





_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, 2008-11-12 at 13:21 +1100, James Harper wrote:
> Is there a limit on the amount of data you can write to the xenstore?
> Overflowing some limit in xenstore could be one method of causing a
> crash.
That''s funny, I was just trying to find where these were set when
xenstored is started:


 --entry-nb <nb>     limit the number of entries per domain,
 --entry-size <size> limit the size of entry per domain, and
 --entry-watch <nb>  limit the number of watches per domain,
 --transaction <nb>  limit the number of transaction allowed per domain,

So if the number of entries per domain (plus size per entry) can be
limited .. it seems that at least --entry-size is not being enforced?

If it were, the only way to overflow the store would be from dom-0,
creating infinite domain entries @ xx bytes each until it exploded.

Argh, I wish I was better with Python.

Cheers,
--Tim


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

> 
> > Is there a limit on the amount of data you can write to the
xenstore?
> > Overflowing some limit in xenstore could be one method of causing a
> > crash.
> 
> That''s funny, I was just trying to find where these were set when
> xenstored is started:
> 
> 
>  --entry-nb <nb>     limit the number of entries per domain,
>  --entry-size <size> limit the size of entry per domain, and
>  --entry-watch <nb>  limit the number of watches per domain,
>  --transaction <nb>  limit the number of transaction allowed per
domain,
> 
> So if the number of entries per domain (plus size per entry) can be
> limited .. it seems that at least --entry-size is not being enforced?
> 
> If it were, the only way to overflow the store would be from dom-0,
> creating infinite domain entries @ xx bytes each until it exploded.
> 
> Argh, I wish I was better with Python.
> 
When testing save/restore under GPLPV, I created some scripts which do
save + restore on a loop and left them running for days. Domain id''s in
the thousands were common during those tests.

It appears that in some DomU failure cases, xenstore entries are not
being cleaned up properly. With enough cruft in there, xenstore
operations start to take a loooong time... operatons that should take
seconds were taking minutes.

A reboot fixed it up of course, but it''s not really ideal. That was
under 3.1.x though so those leaks may have been fixed since then.

It sounds like someone has at least thought about per-domain xenstore
limits though, which is encouraging.

James

_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, Nov 11, 2008 at 8:03 PM, Vasiliy Baranov
<vasiliy.baranov@gmail.com>wrote:
>
> On Tue, Nov 11, 2008 at 5:52 PM, Todd Deshane <deshantm@gmail.com>
wrote:
>
>
>> White hat hackers have been able to find various tricky ways to break
out
>> of
>> the isolation that xen provides, but I haven''t heard of any
exploits that
>> have
>> been taken advantage of in practice.
>> http://theinvisiblethings.blogspot.com/2008/07/0wning-xen-in-vegas.html
>> http://xen.markmail.org/search/?q=Rutkowska
>
>
Following up on this, these two links help a lot.

Thanks again,
Vasiliy


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Tue, Nov 11, 2008 at 10:59 PM, George Lenzer
<george.lenzer@cpl.org>wrote:
> >>>With the kernels and modules, I think that it would only be
wise for you
> to restrict them to the kernel you provide.
> >> Why? Why it matters (if Xen is designed to provide isolation
anyways)?
>
> Not a technical reason, but more a "paranoid" approach just in
case there
> is something flawed in the Xen design.  However, saying that, I personally
> wouldn''t have a problem with custom kernel modules other than the
> administration headaches (maybe rsync or an svn repository would be wise).
>
> >>>Regarding the security of running their own modules, it I still
believe
> that they would not be able to cross the boundaries of their domain into
> other domains via this route.  Unless something is seriously broken in
> >>>the Xen paravirtualization model, when they are in unprivileged
domains,
> they can''t access anything that Domain0/Xen microkernel
doesn''t allow.
>
>> >>I am far from being Linux expert but I thought a module can
override
> anything in the kernel. Am I wrong? If am not wrong, why disallowing custom
> kernels while still allowing custom modules can be different
> >>from allowing custom kernels?
>
> I welcome any correction on my thinking, but if I understand it correctly,
> when you boot a paravirtualized domU, it is using it''s own
instance of the
> domU kernel in RAM.  It is not sharing a kernel with Dom0.  They are the
> same kernel in terms of the binary, but the memory space and virtual
> resource allocated to Domain0 are not accessible to any unprivileged domain
> in any way.  This is why I chose Xen over OpenVZ for my own needs.  I
wanted
> something that didn''t share a kernel instance at all, and
that''s what Xen
> PVs offer.
>
Sure. We are not talking about sharing the kernel between dom0 and domU.
domUs are going to have completely different kernels anyways. The question
is, if I have to allow custom modules in domUs (because my users cannot live
without them), does it make sense to disallow custom kernels, i.e. whether
disallowing custom kernels is going to buy me much?

Thank you,
Vasiliy


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Wed, Nov 12, 2008 at 5:21 AM, James Harper
<james.harper@bendigoit.com.au
> wrote:
>
> When developing the Windows GPLPV drivers I crashed my Dom0 (and
> therefore all DomU''s) on a few occasions. That was under 3.0.3,
3.0.4,
> and possibly some early 3.1.x versions of Xen. As crashing was the exact
> opposite of what I was trying to do, I didn''t pursue it, but
obviously
> it has been possible in the past to cause a crash by doing something
> wrong in the PV side of things.
>
> Is there a limit on the amount of data you can write to the xenstore?
> Overflowing some limit in xenstore could be one method of causing a
> crash.
>
Interesting data point, and question.

Thank you,
Vasiliy


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

"Vasiliy Baranov" <vasiliy.baranov@gmail.com>
writes:
> Sure. We are not talking about sharing the kernel between dom0 and domU.
> domUs are going to have completely different kernels anyways. The question
> is, if I have to allow custom modules in domUs (because my users cannot
live
> without them), does it make sense to disallow custom kernels, i.e. whether
> disallowing custom kernels is going to buy me much?
First, I''m not really sure how you would disallow custom kernels,
without
giving users a box with a castrated root.  If you have root on a 
regular linux box, there are several mechanisms for modifying the running
kernel without rebooting.   

A data point:  I''ve been allowing custom kernels from just about anyone
on the net willing to give me $5 since 2005, and I haven''t had anyone
break
out from the DomU to the Dom0.  

I am entirely paravirtualized, though, and from what I understand, HVM has
a much larger (and theoretically  more buggy) interface between Dom0 and DomU.

I have had problems where MAC address conflicts took things down,  (lock
those MACs down and firewall them!)  

Oh, the weakest part of my system, in my opinion?  PyGrub.  (that, or my
homemade scripts that give DomU owners access to ''xm console
domain'')
Now, I don''t know of any open security holes in PyGrub, but I know
there
were some in the past. 

Essentially, PyGrub is a python script that reads /boot/grub/menu.lst from
the guest file system and then copies the kernel from the DomU to the Dom0.
You can imagine how risky that is.   

PVGRUB, from Xen 3.3, is theoretically much more secure, as it runs 
entirely within the DomU.  




_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users

On Thu, Nov 27, 2008 at 4:03 AM, Luke S Crawford <lsc@prgmr.com> wrote:
> "Vasiliy Baranov" <vasiliy.baranov@gmail.com> writes:
> > Sure. We are not talking about sharing the kernel between dom0 and
domU.
> > domUs are going to have completely different kernels anyways. The
> question
> > is, if I have to allow custom modules in domUs (because my users
cannot
> live
> > without them), does it make sense to disallow custom kernels, i.e.
> whether
> > disallowing custom kernels is going to buy me much?
>
> First, I''m not really sure how you would disallow custom kernels,
without
> giving users a box with a castrated root.

By disallowing custom kernels I mean that dom0 can supply trusted (for some
value of "trusted") kernels rather than invoke pygrub.

> If you have root on a
> regular linux box, there are several mechanisms for modifying the running
> kernel without rebooting.

Can you please name some of these mechanisms?

> A data point:  I''ve been allowing custom kernels from just about
anyone
> on the net willing to give me $5 since 2005, and I haven''t had
anyone break
> out from the DomU to the Dom0.
>
> I am entirely paravirtualized, though, and from what I understand, HVM has
> a much larger (and theoretically  more buggy) interface between Dom0 and
> DomU.
>
> I have had problems where MAC address conflicts took things down,  (lock
> those MACs down and firewall them!)
>
> Oh, the weakest part of my system, in my opinion?  PyGrub.  (that, or my
> homemade scripts that give DomU owners access to ''xm console
domain'')
> Now, I don''t know of any open security holes in PyGrub, but I know
there
> were some in the past.
>
> Essentially, PyGrub is a python script that reads /boot/grub/menu.lst from
> the guest file system and then copies the kernel from the DomU to the Dom0.
> You can imagine how risky that is.

Hmm, I can see security risks in the context of not completely trusted
dom0s. In the context of untrusted domUs, guest FS processing and file
copying does not sound like something too risky. Am I missing something?

> PVGRUB, from Xen 3.3, is theoretically much more secure, as it runs
> entirely within the DomU.
>
Agreed.

Very helpful data point.

Thank you very much,
Vsailiy


_______________________________________________
Xen-users mailing list
Xen-users@lists.xensource.com
http://lists.xensource.com/xen-users