Re: [MirageOS-devel] TLS on Xen

[Anil Madhavapeddy <anil@xxxxxxxxxx>]

On 16 Jan 2015, at 10:04, 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.

The new XenStore+Irmin design separates the Xen and non-Xen specific portions 
into discrete bits.  The transaction and reconciliation portions of XenStore 
are useful in any purely functional distributed database, whereas the 
permission model is very Xen-specific.

So the new design doesn't directly simplify the permissions model, but it does 
distill down the XenStore implementation such that replacing or extending the 
permissions is much simpler than it was before.  The Qubes comment regarding 
"overly complex and unnecessary" is almost right - it's indeed overly complex, 
but a sophisticated permissions model is very much necessary for a 
security-critical system component such as XenStore.

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

Excellent idea!

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