[Hackathon 16] Notes from Security Session

[Hackathon 16] Notes from Security Session

[Lars Kurth]

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 



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

Re: [Hackathon 16] Notes from Security Session

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 8400 bytes --]

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.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [Hackathon 16] Notes from Security Session

[Andrew Cooper]

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

Re: [Hackathon 16] Notes from Security Session

[Konrad Rzeszutek Wilk]

On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
> On 19/04/16 10:02, Doug Goldstein wrote:
> >On 4/18/16 12:20 PM, Lars Kurth wrote:
> >>Hi all,

CC-ing XSM maintainer :-)
> >>
> >>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

Re: [Hackathon 16] Notes from Security Session

[Daniel De Graaf]

On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
>> On 19/04/16 10:02, Doug Goldstein wrote:
>>> On 4/18/16 12:20 PM, Lars Kurth wrote:
>>>> Hi all,
>
> CC-ing XSM maintainer :-)

Thanks. I'm going to comment on this and the wiki.

[...]
>>>> === 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

This should be doable, though it will require moving the rest of
tools/flask/policy under xen/ for proper dependencies. Beyond that, it
would need either a script or a careful invocation of objcopy to convert
the policy output to an array in initdata, and then that policy would be
used if the bootloader one is not present.

 From the wiki:
> XSM with default policy will have:
>
>   - Same functionality exposed to guests without regressions
>   - Have at minimum the same security as we have without XSM enabled.
>   - Have set of policies for device driver domains vs control domains.

The first two bullets should be true with the current policy. The third
needs to be more precisely defined: any operation on a group it
controls, or limited operations (such as adjusting memory size) on all
guests?  The latter will probably need a custom policy (module) for
exactly what the control domain does.

> Known Issues
>
>   - Cannot re-apply a new policy after guests have been running.

This is possible via "xl loadpolicy".  There is no (exposed) way to
re-label existing domains, but you can create new domains using new
types in the policy.  The new policy rules will be enforced immediately
on existing domains, but this may not fully tighten restrictions: for
example, if a passthrough device is newly disallowed but already mapped
by a domain, it will not be unmapped.

> TODO List
>
>   - Could initial build of Xen hypervisor include a built-in (inside .init.data) policy file?
(Above).
>   - Can we make policies modularized? A core (perhaps built-in?) with amendments loaded later?

There is already some support for modules in the XSM policy: see
tools/flask/policy/policy/modules.conf.  Currently this is not really
used: all rules are in the "xen" module.  However, it could be split up
into a real core module (probably still named "xen") and other modules
that would be available to turn on/off.

The process of assembling the modules into a single XSM policy is done
in userspace, not the hypervisor, so "xl loadpolicy" would not change.

-- 
Daniel De Graaf
National Security Agency

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

Re: [Hackathon 16] Notes from Security Session

[Lars Kurth]

Also adding Steve Maresca to the thread, who has been using XSM extensively and also documenting XSM and can provide some user perspective 
Lars

> On 25 Apr 2016, at 20:51, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> 
> On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
>> On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
>>> On 19/04/16 10:02, Doug Goldstein wrote:
>>>> On 4/18/16 12:20 PM, Lars Kurth wrote:
>>>>> Hi all,
>> 
>> CC-ing XSM maintainer :-)
> 
> Thanks. I'm going to comment on this and the wiki.
> 
> [...]
>>>>> === 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
> 
> This should be doable, though it will require moving the rest of
> tools/flask/policy under xen/ for proper dependencies. Beyond that, it
> would need either a script or a careful invocation of objcopy to convert
> the policy output to an array in initdata, and then that policy would be
> used if the bootloader one is not present.
> 
> From the wiki:
>> XSM with default policy will have:
>> 
>>  - Same functionality exposed to guests without regressions
>>  - Have at minimum the same security as we have without XSM enabled.
>>  - Have set of policies for device driver domains vs control domains.
> 
> The first two bullets should be true with the current policy. The third
> needs to be more precisely defined: any operation on a group it
> controls, or limited operations (such as adjusting memory size) on all
> guests?  The latter will probably need a custom policy (module) for
> exactly what the control domain does.
> 
>> Known Issues
>> 
>>  - Cannot re-apply a new policy after guests have been running.
> 
> This is possible via "xl loadpolicy".  There is no (exposed) way to
> re-label existing domains, but you can create new domains using new
> types in the policy.  The new policy rules will be enforced immediately
> on existing domains, but this may not fully tighten restrictions: for
> example, if a passthrough device is newly disallowed but already mapped
> by a domain, it will not be unmapped.
> 
>> TODO List
>> 
>>  - Could initial build of Xen hypervisor include a built-in (inside .init.data) policy file?
> (Above).
>>  - Can we make policies modularized? A core (perhaps built-in?) with amendments loaded later?
> 
> There is already some support for modules in the XSM policy: see
> tools/flask/policy/policy/modules.conf.  Currently this is not really
> used: all rules are in the "xen" module.  However, it could be split up
> into a real core module (probably still named "xen") and other modules
> that would be available to turn on/off.
> 
> The process of assembling the modules into a single XSM policy is done
> in userspace, not the hypervisor, so "xl loadpolicy" would not change.
> 
> -- 
> Daniel De Graaf
> National Security Agency


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

Re: [Hackathon 16] Notes from Security Session

[Konrad Rzeszutek Wilk]

On Tue, Apr 26, 2016 at 09:57:12AM +0100, Lars Kurth wrote:
> Also adding Steve Maresca to the thread, who has been using XSM extensively and also documenting XSM and can provide some user perspective 
> Lars
> 
> > On 25 Apr 2016, at 20:51, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
> > 
> > On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
> >> On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
> >>> On 19/04/16 10:02, Doug Goldstein wrote:
> >>>> On 4/18/16 12:20 PM, Lars Kurth wrote:
> >>>>> Hi all,
> >> 
> >> CC-ing XSM maintainer :-)
> > 
> > Thanks. I'm going to comment on this and the wiki.
> > 
> > [...]
> >>>>> === 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
> > 
> > This should be doable, though it will require moving the rest of
> > tools/flask/policy under xen/ for proper dependencies. Beyond that, it
> > would need either a script or a careful invocation of objcopy to convert
> > the policy output to an array in initdata, and then that policy would be
> > used if the bootloader one is not present.

OK, let me take a stab at that. Unless somebody else is already looking
at this?

> > 
> > From the wiki:
> >> XSM with default policy will have:
> >> 
> >>  - Same functionality exposed to guests without regressions
> >>  - Have at minimum the same security as we have without XSM enabled.
> >>  - Have set of policies for device driver domains vs control domains.
> > 
> > The first two bullets should be true with the current policy. The third
> > needs to be more precisely defined: any operation on a group it
> > controls, or limited operations (such as adjusting memory size) on all
> > guests?  The latter will probably need a custom policy (module) for
> > exactly what the control domain does.

Hm. I would have thought that device driver domains would have
limited operations. As in they can do grant maps, PCIe access, etc.
But they cannot do the operations that dom0 has done.

Doug, didn't you do some of this already?
> > 
> >> Known Issues
> >> 
> >>  - Cannot re-apply a new policy after guests have been running.
> > 
> > This is possible via "xl loadpolicy".  There is no (exposed) way to
> > re-label existing domains, but you can create new domains using new
> > types in the policy.  The new policy rules will be enforced immediately
> > on existing domains, but this may not fully tighten restrictions: for
> > example, if a passthrough device is newly disallowed but already mapped
> > by a domain, it will not be unmapped.

Would the audit code mention this? Ah I presume not as the operation
has already been completed and the IOMMU access and such do not do XSM
checks.

But it is good to know that you can relable existing domains.
I was under the mistaken impression you couldn't!

> > 
> >> TODO List
> >> 
> >>  - Could initial build of Xen hypervisor include a built-in (inside .init.data) policy file?
> > (Above).
> >>  - Can we make policies modularized? A core (perhaps built-in?) with amendments loaded later?
> > 
> > There is already some support for modules in the XSM policy: see
> > tools/flask/policy/policy/modules.conf.  Currently this is not really
> > used: all rules are in the "xen" module.  However, it could be split up
> > into a real core module (probably still named "xen") and other modules
> > that would be available to turn on/off.

That is quit appealing. Especially when it comes to working on
say device driver domains and having the 'core' Xen one there while
I can futz around with device driver one.

> > 
> > The process of assembling the modules into a single XSM policy is done
> > in userspace, not the hypervisor, so "xl loadpolicy" would not change.

/me nods

Thank you! 

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

Re: [Hackathon 16] Notes from Security Session

[Doug Goldstein]

[-- Attachment #1.1.1: Type: text/plain, Size: 4656 bytes --]

On 5/17/16 4:08 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 26, 2016 at 09:57:12AM +0100, Lars Kurth wrote:
>> Also adding Steve Maresca to the thread, who has been using XSM extensively and also documenting XSM and can provide some user perspective 
>> Lars
>>
>>> On 25 Apr 2016, at 20:51, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>
>>> On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
>>>> On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
>>>>> On 19/04/16 10:02, Doug Goldstein wrote:
>>>>>> On 4/18/16 12:20 PM, Lars Kurth wrote:
>>>>>>> Hi all,
>>>>
>>>> CC-ing XSM maintainer :-)
>>>
>>> Thanks. I'm going to comment on this and the wiki.
>>>
>>> [...]
>>>>>>> === 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
>>>
>>> This should be doable, though it will require moving the rest of
>>> tools/flask/policy under xen/ for proper dependencies. Beyond that, it
>>> would need either a script or a careful invocation of objcopy to convert
>>> the policy output to an array in initdata, and then that policy would be
>>> used if the bootloader one is not present.
> 
> OK, let me take a stab at that. Unless somebody else is already looking
> at this?

I know I pitched this out and said I had planned on working on it but
the realities of life have set in and I likely won't really be able to
put an honest amount of effort into this for a few more weeks. I think a
bulk of the work will really be testing and documenting instead of
coding because as we said it should just be a few commands and a few if
checks.

> 
>>>
>>> From the wiki:
>>>> XSM with default policy will have:
>>>>
>>>>  - Same functionality exposed to guests without regressions
>>>>  - Have at minimum the same security as we have without XSM enabled.
>>>>  - Have set of policies for device driver domains vs control domains.
>>>
>>> The first two bullets should be true with the current policy. The third
>>> needs to be more precisely defined: any operation on a group it
>>> controls, or limited operations (such as adjusting memory size) on all
>>> guests?  The latter will probably need a custom policy (module) for
>>> exactly what the control domain does.
> 
> Hm. I would have thought that device driver domains would have
> limited operations. As in they can do grant maps, PCIe access, etc.
> But they cannot do the operations that dom0 has done.
> 
> Doug, didn't you do some of this already?

So I've made a domD_t but I'm not sure how encompassing it is. I've
thought about making the "driver_domain=BOOL" parameter apply that label
over domU_t but right now its just done through "seclabel". I can post
what I've got as a RFC.

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

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

Re: [Hackathon 16] Notes from Security Session

[Daniel De Graaf]

On 05/17/2016 05:08 PM, Konrad Rzeszutek Wilk wrote:
> On Tue, Apr 26, 2016 at 09:57:12AM +0100, Lars Kurth wrote:
>> Also adding Steve Maresca to the thread, who has been using XSM extensively and also documenting XSM and can provide some user perspective
>> Lars
>>
>>> On 25 Apr 2016, at 20:51, Daniel De Graaf <dgdegra@tycho.nsa.gov> wrote:
>>>
>>> On 04/25/2016 02:32 PM, Konrad Rzeszutek Wilk wrote:
>>>> On Tue, Apr 19, 2016 at 10:11:28AM +0100, Andrew Cooper wrote:
>>>>> On 19/04/16 10:02, Doug Goldstein wrote:
>>>>>> On 4/18/16 12:20 PM, Lars Kurth wrote:
>>>>>>> Hi all,
>>>>
>>>> CC-ing XSM maintainer :-)
>>>
>>> Thanks. I'm going to comment on this and the wiki.
>>>
>>> [...]
>>>>>>> === 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
>>>
>>> This should be doable, though it will require moving the rest of
>>> tools/flask/policy under xen/ for proper dependencies. Beyond that, it
>>> would need either a script or a careful invocation of objcopy to convert
>>> the policy output to an array in initdata, and then that policy would be
>>> used if the bootloader one is not present.
>
> OK, let me take a stab at that. Unless somebody else is already looking
> at this?

I have an RFC patch that I'll send in a moment.

>>>
>>>  From the wiki:
>>>> XSM with default policy will have:
>>>>
>>>>   - Same functionality exposed to guests without regressions
>>>>   - Have at minimum the same security as we have without XSM enabled.
>>>>   - Have set of policies for device driver domains vs control domains.
>>>
>>> The first two bullets should be true with the current policy. The third
>>> needs to be more precisely defined: any operation on a group it
>>> controls, or limited operations (such as adjusting memory size) on all
>>> guests?  The latter will probably need a custom policy (module) for
>>> exactly what the control domain does.
>
> Hm. I would have thought that device driver domains would have
> limited operations. As in they can do grant maps, PCIe access, etc.
> But they cannot do the operations that dom0 has done.

For pure device driver domains, this is true: they can just use domU_t and
be done.  The custom types would be needed for (non-dom0) control domains.

> Doug, didn't you do some of this already?
>>>
>>>> Known Issues
>>>>
>>>>   - Cannot re-apply a new policy after guests have been running.
>>>
>>> This is possible via "xl loadpolicy".  There is no (exposed) way to
>>> re-label existing domains, but you can create new domains using new
>>> types in the policy.  The new policy rules will be enforced immediately
>>> on existing domains, but this may not fully tighten restrictions: for
>>> example, if a passthrough device is newly disallowed but already mapped
>>> by a domain, it will not be unmapped.
>
> Would the audit code mention this? Ah I presume not as the operation
> has already been completed and the IOMMU access and such do not do XSM
> checks.

The audit code would catch the policy reload, and it might find (and deny)
operations by PV domains doing a remap of the device mapping.  HVM domains
(especially ones using EPT) don't hit XSM code when adjusting that mapping,
only when it is initially added to the guest to machine mapping.

> But it is good to know that you can relable existing domains.
> I was under the mistaken impression you couldn't!

This is only exposed at the libxc level (xc_flask_relabel_domain), and it
is discouraged as the "doesn't revoke existing mappings" aspect, if not
taken into consideration, can make you think the system is more secure than
it actually is.

>>>
>>>> TODO List
>>>>
>>>>   - Could initial build of Xen hypervisor include a built-in (inside .init.data) policy file?
>>> (Above).
>>>>   - Can we make policies modularized? A core (perhaps built-in?) with amendments loaded later?
>>>
>>> There is already some support for modules in the XSM policy: see
>>> tools/flask/policy/policy/modules.conf.  Currently this is not really
>>> used: all rules are in the "xen" module.  However, it could be split up
>>> into a real core module (probably still named "xen") and other modules
>>> that would be available to turn on/off.
>
> That is quit appealing. Especially when it comes to working on
> say device driver domains and having the 'core' Xen one there while
> I can futz around with device driver one.

I tried making this work last week, and I think I'll post what I have now
instead of waiting until after 4.7 has been branched.

>>>
>>> The process of assembling the modules into a single XSM policy is done
>>> in userspace, not the hypervisor, so "xl loadpolicy" would not change.
>
> /me nods
>
> Thank you!
>

-- 
Daniel De Graaf
National Security Agency

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