Xen project Mailing List

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)

> 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

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

Cheers,

Dave

Re: [MirageOS-devel] TLS on Xen