Re: [MirageOS-devel] TLS on Xen

[Thomas Leonard <talex5@xxxxxxxxx>]

On 16 January 2015 at 13:25, David Scott <scott.dj@xxxxxxxxx> wrote:
>
>
> On Fri, Jan 16, 2015 at 10:04 AM, Thomas Leonard <talex5@xxxxxxxxx> wrote:
>>
>> On 16 January 2015 at 08:51, Anil Madhavapeddy <anil@xxxxxxxxxx> wrote:
>> > On 16 Jan 2015, at 00:00, Thomas Gazagnaire <thomas@xxxxxxxxxxxxxx>
>> > wrote:
>> >>
>> >>>> On 15 January 2015 at 17:58, Thomas Gazagnaire
>> >>>> <thomas@xxxxxxxxxxxxxx> wrote:
>> >>>>>> - It would be good if you could configure an https server directly
>> >>>>>> in
>> >>>>>> config.ml. Currently, the need to configure it with a certificate
>> >>>>>> and
>> >>>>>> private key means this step has to go in the unikernel.
>> >>>>>
>> >>>>> would it be possible to do something like for the IP address where
>> >>>>> we write the IP address in config.ml and then generate main.ml with 
>> >>>>> the same
>> >>>>> IP printed in (ie. we "lift" the IP value from the configuration 
>> >>>>> language to
>> >>>>> the main program)? Is there a way to print a server configuration as a
>> >>>>> string which can be interpreted as an OCaml value?
>> >>>>
>> >>>> What's the recommended way to store the private key? I don't want it
>> >>>> in config.ml because that's part of the source repository. I could
>> >>>> load it there. I can't deploy via a public GitHub repository if the
>> >>>> binary contains the key, so maybe it should be stored on a block
>> >>>> device?
>> >>>
>> >>> At the risk of abusing XenStore too much, it could also be written
>> >>> there
>> >>> with suitably constrained permissions.  It would still need to be a
>> >>> block
>> >>> device for normal cloud providers though.
>> >>
>> >> maybe you can load the key when configuring your unikernel ie. it
>> >> should be available on the filesystem (or somewhere else) where you are
>> >> configuring your unikernel.
>> >>
>> >> in that case you can:
>> >> - in config.ml: call a function to read the private key
>> >> - in main.ml: you can generate some code with the hard-coded private
>> >> key read while configuring
>> >
>> > This doesn't meet the requirement that the binary can be redistributed
>> > on a public site (ala mirage-www-deployment).
>> >
>> >> Regarding xenstore: I'm still a bit uncomfortable with passing dynamic
>> >> secret data in there
>> >
>> > It does require some thought for sure -- but Xenstore is already a
>> > highly trusted component that can only be accessed by the root user in the
>> > guest kernel on conventional operating systems.
>>
>> I don't understand the XenStore permission system well enough to
>> comment on whether putting secrets there is safe, but I notice that
>> Qubes replaced it:
>>
>> "One interesting thing about Qubes DB is that it get rids of the
>> (overly complex and unnecessary) permission system that is used by
>> xenstore, and instead uses the most simple approach: each VM has its
>> separate Qubes DB daemon, and so a totally separate
>> configuration/state namespace. This is inline with the rest of the
>> Qubes philosophy, which basically says that: permissions is dead, long
>> live separation!"
>>
>>
>> http://theinvisiblethings.blogspot.co.uk/2013/06/qubes-os-r3-alpha-preview-odyssey-hal.html
>>
>> I don't know whether the new XenStore design changes things here.
>
>
> I've been wondering about Qubes -- did you happen to notice whether guest
> VMs still use netfront and blkfront? To use those drivers out-of-the-box
> they would need some kind of Xenstore shim. I've been thinking about that
> anyway because we're starting to see scalability problems be caused by the
> shared namespace (e.g. /local/domain is too large)

Sorry, I don't know anything else except what's in that blog post.

>> > If not Xenstore itself, then some other channel of a similar nature
>> > (like Xentropyd has) would fit the bill.  Unfortunately, this won't work on
>> > a public cloud provider, but a block device should be fine there.
>> >
>> > Thinking about the block device more, perhaps we could have the notion
>> > of a transient block device -- attach it at boot to read the private key
>> > into memory, and then immediately eject it.
>>
>> I was thinking of putting it in its own partition on the main disk
>> (and create a partition functor). People already expect disks to
>> contain private data, including keys, so that should be OK, and it
>> should be easy to see from the code that only the TLS system has
>> access to that data.
>
>
> A partition on the main disk sounds fine. You could use ocaml-mbr:
>
> https://github.com/mirage/ocaml-mbr

Ah, nice, that saves me writing my own version!

> There's also an implementation of LVM but that's overkill :-)


-- 
Dr Thomas Leonard        http://0install.net/
GPG: 9242 9807 C985 3C07 44A6  8B9A AE07 8280 59A5 3CC1
GPG: DA98 25AE CAD0 8975 7CDA  BD8E 0713 3F96 CA74 D8BA

_______________________________________________
MirageOS-devel mailing list
MirageOS-devel@xxxxxxxxxxxxxxxxxxxx
http://lists.xenproject.org/cgi-bin/mailman/listinfo/mirageos-devel