Re: [Hackathon 16] Notes from Security Session

[Andrew Cooper <andrew.cooper3@citrix.com>]

On 19/04/16 10:02, Doug Goldstein wrote:
> On 4/18/16 12:20 PM, Lars Kurth wrote:
>> Hi all,
>>
>> I took notes as much as I could. CC'ed the people who participated most. If I missed/misrepresented something, please add to the discussion. I know that George for example took some extra notes in the one or other area.
>>
>> Regards
>> Lars
>>
>> == Topics discussed ==
>> QEMU
>> De-privilige of QEMU
>> XSA
>> x-Splice
>> x86 Emulator
>> Enabling XSM By default
>>
>> === Slimline QEMU ===
>>
>> Konrad: Some inroads on making QEMU better
>> Konrad: QEMU is too big and it is hard to strip down the platform : how can we chop it up
>>
>> Wei: Wei attempted this 2 years ago : Wei defined some Xen stub CPU model, which was rejected at the time
>> Stefano: Maybe what we need is different
>> Stefano: Containers / Intel have similar issues
>> Stefano: Intel have a very similar problem with ClearContainer
>> Stefano: Re-implementing ClearContainers with QEMU because of market needs
>> Stefano: QEMU does have already a no-default option
>>
>> Doug: In the QEMU model: you cannot run a board without a CPU
>> Doug: KConfig may be acceptable, but re4moving boards may not (initially discussed with Antony L)
>>
>> George: Distros don't want to ship two versions of QEMU
>> George: Compile configurability doesn't help with distros
>>
>> Konrad: PVH/HVMLite does not use QEMU (or only as a back)
>>
>> Lars: If we had a proposal, working with Intel and the QEMU community, we could discuss at Xen Summit / KVM Forum is co-located
>>
>> James: If we had a future with OVMF, then we probably wouldn't need QEMU (aka if you want security use PVH with OVMF)
>> James: Proposal for security conscious applications we could fork and use a stubbed out version of QEMU
>>
>> Options:
>> - KConfig
>> - Run-time disablement
>> - Xen Summit / KVM Forum
>> - Intel work / collaboration
>> - PIX3 > 935
>> - OVMF
>> - Remove xl.cfg (stop configs - in fact we probably only can print a warning "this is not secure and has no security support" or something similar)
>>
>> Doug: Issue
>> - For example Oracle could deal with Config
>> - BUT, this approach won't work for distros
>>
>> ACTION: Konrad is volunteering to drive this discussion
>>
>> === De-privilige Qemu ===
>> Konrad: What's the status
>> Stefano: not done, you need
>> - QEMU as non-root (that is in 4.7 and QEMU part is there)
>> - Now you still have a libxc and xenstore interface that needs to be de-priviliged
>>    - There is a patch for QEMI and xenstore to deal with the libxc part (not upstreamed) ... pretty big series, but won't make it for 4.7 - QEMU part is tiny
>>    - Libxc is sizeable (Ian Campbell was working on it), but it is now dormant : QEMU support is there, but Dom0 interface is missing
>>      - Ideas: Do registration in Dom0
>> [George has some additional notes]
>>
>> ISSUE: A proposal and a plan, but nobody to do this. Without this what we have is not useful
>> Andrew: XenServer still using qemu-trad because of some gaps in emu-upstream
>> Andrew: XS may end up working on this at some undefined point in the future
>>
>> There is a problem with using CD drive's to open ISOs as you need to be privileged to do this
>> Andy Cooper: there may be real end-user issues
>> Stefano: Could change ownership
>> Doug: Issue was tried to be fixed in libvirt and went nowhere
>> Andy: Qemu-trad does it wrong (QEMU in libxenlight does not do that)
>>
>> ACTION: High;right lack of owner
>>
>> Konrad: Seccomp may work
>> Doug: everything has to be passed as file descriptor
>>
>> === Narrower XSA Coverage ===
>> Jan: XSA 77 (whitelisted a set of dom control and sys control) which are supposedly ... http://xenbits.xen.org/xsa/advisory-77.html
>>       See http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt (Security Status of dom0 disaggregation)
>> Jan: Who runs this in production: running part of toolstack not in Dom0 - OpenXT wants to do this
>> Jan: The observation is that we went to far with the XSA 77 => if we had a shorter whitelist, and reduce whitelist
>> Jan: If there was agreement, then the security team
>>   would not handle issues in these areas as XSA's
>>
>> Ross Phillipson: Typic ally we have only higher level stuff in a different xl, but lower level stuff runs on Dom0. So there should be no issue
>>
>> George: QEMU stub domains should have security support
>> George: There are a whole set of other things, which we don't know whether they are used
>> George: Do we want to security support of disaggregated tools-stub
>>
>> Agreed: Propose patch to change http://xenbits.xen.org/docs/unstable/misc/xsm-flask.txt on the list
>> Jan: We can only discuss in public if no issues are pending
>> Cc: Christopher Clark <christopher.w.clark@gmail.com>, Ross Philipson <ross.philipson@gmail.com>, Daniel Smith <dpsmith@apertussolutions.com>
>> CC the folks on this thread or openxt@googlegroups.com (OpenXT mailing list)
>>
>> === x86 Emulation de-privilige ===
>> Anthony is working on it
>> Stefano: I think you had some measurements
>> Anthony: Measurements were not very good
>> Andrew: If you are introspecting, you sacrifice 70% performance
>> Andrew: Patches were very complicated
>> Andrew: Re-writing the emulator would only fix the outbound path
>> Stefano: Risk would probably go from High/Critical to Low in terms of impact but not remove the issues
>> Jan: The issue is really with in-guest security issues
>> Doug: Could we look at QEMU emulator
>> Andrew: Did this, but does not seem a good enough baseline
>> James: Have a set of patches which may fix this issue
>> Jan: Would still not fix in-guest security issues
>> Andrew: Reduces the severity of XSAs
>>
>> Konrad: We still want this?
>> Jan: If it is doable, then yes ...
>> Andrew: Huge amount of extra set-up in HV
>>
>> ACTION: James to sent patches as RFC to xen-devel@
>>
>> Jan: The real issue is the quality and maintainability of emulator code
>> Konrad: Two paths - emulator code more robust or de-privilege emulator
>>
>>
>> === x-Splice ===
>> Konrad: At some point, we can provide catches for which we can create payloads
>> Konrad: There are areas which are difficult to do, such as patching data
>> Konrad: Questions - if we had xSplice - should we publish patches to generate the "payload" and as we have in the past
>>
>> Andrew: believes that there are only a small number of XSA's that could not easily be changed into payloads
>>
>> Agreement: do this as a best-effort
>>
>> James: Asks whether chaining patches is an issue
>> Konrad: No issues, but you should deploy binary patches ...
>>
>> Konrad: Can you deploy
>> Jan: Same as with deploying binaries
>> Lars: Could just change the boilerplate
>>
>> Ross: Is there a way to encode dependencies
>> Konrad: Yes
>>
>> === Enabling XSM By default ===
>> Andrew: There are some issues which we need to work through; a lot of little paper cuts
>> Rich: Could we create a list of issues on the wiki?
>> Lars: Definitely
>> Doug: Could we not have a policy which is equivalent to XSM being compiled out
>> Andrew: Could make policy more modular instead of one big global policy
>>
>> Re-apply policy of guest after running
>>
>> ACTION: Need a wiki page, Konrad can start one and we can collaboratively flesh it out
>> Lars: See http://wiki.xenproject.org/wiki/XSMAsDefault_TODO_List
>>
>> ACTION: Konrad and others to add detail to it
>>
>>
> It was pointed out to me that I did not get my comments about XSM across
> clearly. I believe we need to improve the default policy to be
> equivalent to disabling XSM and/or create a policy called "dummy" that
> is the same as XSM disabled. To make XSM usage more smooth I propose we
> bake the default policy into .initdata so that when you boot Xen
> compiled with XSM you are no worse off than compiling XSM out.
>
> The rationale here is that prior to a recent commit when you compiled
> Xen with XSM enabled but did not provide a default policy then any domUs
> that you ran had as much access as dom0. The recent commit changed it so
> that Xen by default does not boot without a policy.
>
> With my proposed change we would have "dummy" that would compile in and
> if you provided another policy it would be used instead or you could
> late load a replacement policy. Basically filling the gap of turning on
> XSM and having a system less secure than XSM off until you developed
> your policy.

+1.  It also avoids needing to play around loading an extra file as a 
grub module, which makes distro-integration easer.

~Andrew

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel