Mailing List Archive

Building domains as a lesser user (was Re: boot loaders for domain != 0)
> Then libext2 would have to run as a non-root user, and feed its output
> to a root process doing the actual domain building, assuming that
> there is no way of making the domain builder or libz choke on the
> kernel image that is...
>
> For real security, all this stuff has to be happen within the domU. In
> a perfect world, privileged code should never read user-supplied data,
> but given that this world is not perfect, you could relax that to not
> reading any variable-length user-supplied data.
>
I've been thinking about this and it seems to get worse and worse the
more I think about it. Pushing loading off to domU isn't much better
because you still need to load a boot loader of some sort. At what
point do we then have to implement support for loading the boot loader
from domU's device (in order to support exotic boot scenarios like
booting from a CD, BOOTP, etc.).

As an alternative, I was trying to see if there was a way do create a
domain as a non-root user. Since root can set up the shared memory
segments, it seems like the builder should be able to drop to a lesser
user. It could even enter a chroot() so that the only potential attack
vector is a syscall exploit (which are rare and well-known enough that
that seems to be acceptable).

That would kind of take some of the pressure off of the domain creator
too. Does this seem like something that's feasible?

Regards,
Anthony Liguori

> Given that both the (perhaps compressed) ELF image and the Ext2
> filesystem contain variable-length data, neither should be read by
> code in dom0.
>
> Jacob
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel
>


--
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
RE: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
> I've been thinking about this and it seems to get worse and worse the
> more I think about it. Pushing loading off to domU isn't much better
> because you still need to load a boot loader of some sort. At what
> point do we then have to implement support for loading the
> boot loader
> from domU's device (in order to support exotic boot scenarios like
> booting from a CD, BOOTP, etc.).

One fairly simple option is to use Linux as a domU boot loader. Boot
with an intrd,
mount the specified filesystem, read off grub.conf, display a menu over
the xencons, kexec the appropriate kernel.

I'd have to think through whether kexec would need modifications, but I
believe it uses the same 32 bit kernel entry point that xen/linux does
(no grubby 16bit nastiness).

This sounds quite a good soloution.

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
RE: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
On Fri, 2005-02-04 at 02:30 +0000, Ian Pratt wrote:
> One fairly simple option is to use Linux as a domU boot loader. Boot
> with an intrd, mount the specified filesystem, read off grub.conf, display a menu over
> the xencons, kexec the appropriate kernel.

Linux really seems like a very heavy hammer for something like this.
Even just thinking from a resource perspective, why boot up a whole
kernel to do nothing more than read an fs and mount another kernel.
Especially as you start thinking about things like modular fs's, etc,
it's going to be much less clean of a solution and be a significant
slowdown on your guest boot time.

And then, it's yet another kernel to keep updated, etc.

Jeremy



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Anthony Liguori wrote:
>
>> Then libext2 would have to run as a non-root user, and feed its output
>> to a root process doing the actual domain building, assuming that
>> there is no way of making the domain builder or libz choke on the
>> kernel image that is...
>>
>> For real security, all this stuff has to be happen within the domU. In
>> a perfect world, privileged code should never read user-supplied data,
>> but given that this world is not perfect, you could relax that to not
>> reading any variable-length user-supplied data.
>>
> I've been thinking about this and it seems to get worse and worse the
> more I think about it. Pushing loading off to domU isn't much better
> because you still need to load a boot loader of some sort. At what
> point do we then have to implement support for loading the boot loader
> from domU's device (in order to support exotic boot scenarios like
> booting from a CD, BOOTP, etc.).

My system uses a two-stage process. Dom0 builds the VM from an ELF file
which is trusted not to take the builder down, but not trusted otherwise.

You then contact the VM using TCP, and you upload your 'real' bootloader
in there as an ELF image and it takes over the TCP connection and does
the rest. In the Linux example the 'real' bootloader is a more complete
ELF decoder, which is able to decode an incoming Linux kernel ELF image
with an optional initrd.

In other cases, such as an incoming migration, the 'real' loader just
knows how to receive pages and adjust incoming page tables. So the
architecture itself does not care if I am loading Linux, doing a
migration, or whatever.

The point is that the initial bootloader image is trusted not to exploit
the domain builder, because it is written and compiled by me (the admin)
and takes no user input before being in a domU, whereas subsequent
'exotic' bootloaders do not have to be trusted at all.

For CD or BOOTP you could do something similar, having a small loader
for each type of media, and a stage2 (possibly just a ported grub) that
does all the heavy lifting.

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Anthony Liguori wrote:

> As an alternative, I was trying to see if there was a way do create a
> domain as a non-root user. Since root can set up the shared memory
> segments, it seems like the builder should be able to drop to a lesser
> user. It could even enter a chroot() so that the only potential attack
> vector is a syscall exploit (which are rare and well-known enough that
> that seems to be acceptable).
>

If we trust Linux to enforce security, we do not need Xen at all ;-)

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Ian Pratt wrote:

>One fairly simple option is to use Linux as a domU boot loader. Boot
>with an intrd,
>mount the specified filesystem, read off grub.conf, display a menu over
>the xencons, kexec the appropriate kernel.
>
>I'd have to think through whether kexec would need modifications, but I
>believe it uses the same 32 bit kernel entry point that xen/linux does
>(no grubby 16bit nastiness).
>
>
Yeah, I think kexec would work but unfortunately it's not part of the
kernel yet. It could be folded into Xen but I agree with Jeremy that it
seems like overkill. Boot through Linux just to get to a grub screen
seems a little strange too.

Jacob's two-stage approach would work although it requires a lot of
custom code. It also makes it pretty difficult to support new types of
loaders. And you still have a point of failure with that "trusted"
loader. I don't think you ever really see a graphical boot using this
approach either. Getting a system going with xlibs working would
basically put you back at the kexec() solution.

I've got the user-space boot loader working quite nicely. I want to
test at the systems in the office though so I'll post it sometime
tomorrow. In the very least, it can be used a data point. It seems
like a very appealing solution if the security concerns can be addressed.

Regards,

Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Jacob Gorm Hansen wrote:

> Anthony Liguori wrote:
>
> If we trust Linux to enforce security, we do not need Xen at all ;-)
>
The current architecture of Xen requires that we trust whatever is
running in Domain-0. The problems being cited wouldn't be a problem if
you could create domains from unpriviledged Domains because you could
have creator Domains who could be created from a trusted source and used
as a buffer against attack.

No matter what, you're trusting some non-Xen piece of software to
enforce security within Domain-0, unless the next step in Xen is to
write a Domain-0 OS :-)

Regards,

--
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Anthony Liguori wrote:

> Jacob's two-stage approach would work although it requires a lot of
> custom code. It also makes it pretty difficult to support new types of
> loaders. And you still have a point of failure with that "trusted"
> loader.

I would disagree that the trusted loader is a point of failure. It is
not trusted in the sense that we need to trust its code to behave
correctly, all we need is to trust it as not being malformed data that
can trigger an exploit in the domain builder, and of course it is not,
given that it is supplied by you the admin and not by a (potentially
hostile) user.

Anyway, this code is already written for Xen 1.3. You can find it at
http://www.diku.dk/~jacobg/self-migration/

Jacob



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Jacob Gorm Hansen wrote:

> I would disagree that the trusted loader is a point of failure. It is
> not trusted in the sense that we need to trust its code to behave
> correctly, all we need is to trust it as not being malformed data that
> can trigger an exploit in the domain builder, and of course it is not,
> given that it is supplied by you the admin and not by a (potentially
> hostile) user.

Well, it's not the same as trusting a Domain's filesystem to be proper.
But it still requires trusting that there are no exploitable bugs in the
software.

Using a lesser-user to create the domain within Domain-0 requires
trusting there are no exploitable bugs in the kernel syscall interfaces.

So, it's a point of failure as much as Linux is.

> Anyway, this code is already written for Xen 1.3. You can find it at
> http://www.diku.dk/~jacobg/self-migration/

Awesome! This is pretty cool stuff. Do you have plans to update for
Xen 2.0/Linux 2.6? Kernel-driven migration seems like an appealing topic.

Regards,

> Jacob
>
>


--
Anthony Liguori
anthony@codemonkey.ws



-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Anthony Liguori wrote:
> Jacob Gorm Hansen wrote:
>
>> Anthony Liguori wrote:
>>
>> If we trust Linux to enforce security, we do not need Xen at all ;-)
>>
> The current architecture of Xen requires that we trust whatever is
> running in Domain-0. The problems being cited wouldn't be a problem if
> you could create domains from unpriviledged Domains because you could
> have creator Domains who could be created from a trusted source and used
> as a buffer against attack.

If you start having domains that can create other domains, IPC, shared
memory between domains, all that, you have essentially turned Xen into a
microkernel, and you start having all sorts of funny issues like access
control, domain ownership, QoS crosstalk and whatnot. And in ten years
from now someone will have to invent a new VMM layer to put below Xen
only to get another fresh start. I am sure the original UNIX also seemed
elegant at first, in the days when it didn't have 250+ different syscalls...

Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
Anthony Liguori wrote:

> Well, it's not the same as trusting a Domain's filesystem to be proper.
> But it still requires trusting that there are no exploitable bugs in the
> software.

Except that the attacker never gets his hand on any of this data. It is
like telling you to exploit my mother's win95 box without the network or
the keyboard being plugged in.

> Using a lesser-user to create the domain within Domain-0 requires
> trusting there are no exploitable bugs in the kernel syscall interfaces.
>
> So, it's a point of failure as much as Linux is.

Well, I do not agree with you there.

>> Anyway, this code is already written for Xen 1.3. You can find it at
>> http://www.diku.dk/~jacobg/self-migration/

> Awesome! This is pretty cool stuff. Do you have plans to update for Xen 2.0/Linux 2.6? Kernel-driven migration seems like an appealing topic.

I would like to, now that it seems xend is going to be slimmed down.
However, my time to work on this is a bit limited for the next six
months :-(

thanks,
Jacob


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
RE: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
On Thu, 3 Feb 2005, Jeremy Katz wrote:

> Linux really seems like a very heavy hammer for something like this.
> Even just thinking from a resource perspective, why boot up a whole
> kernel to do nothing more than read an fs and mount another kernel.

Because it's actually fast, it keeps things simple, and as root file
systems get more and more complex you're going to be faced with putting
more and more crud into the boot loader to read the file system, or just
bite the bullet and use the os to boot the os.

On our 1700 node opteron cluster, and our 1024 node cluster, and our 256
node clusters, and our many 128 node clusters, we use linux as a bootstrap
all the time. We boot linux from linuxbios and then that first linux boots
the real real linux. And, interestingly enough, it's faster than dedicated
bootstraps like etherboot. Having linux boot linux has been shown, for our
cases, to be same or faster way to boot than conventional bootstraps.

For systems like Plan 9, the primary file system (e.g. fossil) is run by a
process, the format is complex (fossil is a write cache for another file
system called venti), and you're just not going to get a simple bootstrap
to parse a fossil partition. So I expect at some point that I'll boot the
domU plan 9 kernel with xm create and I can use that kernel to boot the
real kernel for plan 9 guests.

(first I gotta catch up with xen 3 and get smp guests working, yikes, you
xen guys make me work hard to keep up!)

So, I have no idea if I agree with you or not, but the decision is not
simple, to say the least.

ron


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
RE: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
> The current architecture of Xen requires that we trust whatever is
> running in Domain-0. The problems being cited wouldn't be a
> problem if
> you could create domains from unpriviledged Domains because you could
> have creator Domains who could be created from a trusted
> source and used
> as a buffer against attack.

It's always been part of the plan to be able to delegate dom0 functions
to enable one domain to be given control over another e.g. to create it,
map its pages, stop/start, debug etc.

It just hasn't been a priority to implement this, but it's the direction
we're heading with some of the security work.

Of course, we'll have to rename dom0_op to something else :-)

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
RE: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
> Yeah, I think kexec would work but unfortunately it's not part of the
> kernel yet. It could be folded into Xen but I agree with
> Jeremy that it
> seems like overkill. Boot through Linux just to get to a grub screen
> seems a little strange too.

The 'action' part of kexec is very arch specific, and the Xen
environment make it easily to implement. We don't have to wory about
shutting down virtual devices or such like as they will recover
automatically.

Knocking up an arch xen kexec should be easy.

We could implement the system call in arch Xen even though it isn't in
the mainstream kernel yet.

Ian


-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
Re: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
On Thu, 3 Feb 2005, Anthony Liguori wrote:

> Yeah, I think kexec would work but unfortunately it's not part of the kernel
> yet. It could be folded into Xen but I agree with Jeremy that it seems like
> overkill. Boot through Linux just to get to a grub screen seems a little
> strange too.

FYI. IT comes stanard with AKPM kernel's just grab something recent (ie
2.6.10 or newer) from

http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/

and you get kexec by default.




-------------------------------------------------------
This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
Tool for open source databases. Create drag-&-drop reports. Save time
by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
Download a FREE copy at http://www.intelliview.com/go/osdn_nl
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel
RE: Building domains as a lesser user (was Re: boot loaders for domain != 0) [ In reply to ]
On Fri, 2005-02-04 at 06:33, Ian Pratt wrote:

> We could implement the system call in arch Xen even though it isn't in
> the mainstream kernel yet.

Attached is a newer version of the grub menu. Also contains a /linuxrc
that will kexec. Turns out that the menu code stays the same for doing
it via kexec or in dom0.

So all that's left is for someone to port kexec to Xen. I won't get to
it for a while so hopefully someone else can jump in..

I looked at the kexec code and it looks like it will map to Xen fairly
painlessly.

Regards,

--
Anthony Liguori
Linux Technology Center (LTC) - IBM Austin
E-mail: aliguori@us.ibm.com
Phone: (512) 838-1208

Signed-off-by: Anthony Liguori