> 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
> 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