Re: [MirageOS-devel] TLS on Xen

[Thomas Leonard <talex5@xxxxxxxxx>]

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.

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


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