From mboxrd@z Thu Jan 1 00:00:00 1970 From: Doug Goldstein Subject: Re: [Hackathon 16] Notes from Security Session Date: Wed, 18 May 2016 22:31:29 -0500 Message-ID: References: <5715F43E.7090503@cardoe.com> <5715F640.1070206@citrix.com> <20160425183229.GB13411@char.us.oracle.com> <571E7524.8070005@tycho.nsa.gov> <1445CEA7-78E1-428B-BD7C-757B2B8EB684@gmail.com> <20160517210843.GD7179@char.us.oracle.com> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============0226877314483608572==" Return-path: Received: from mail6.bemta3.messagelabs.com ([195.245.230.39]) by lists.xenproject.org with esmtp (Exim 4.84_2) (envelope-from ) id 1b3EgT-0003DF-0J for xen-devel@lists.xenproject.org; Thu, 19 May 2016 03:31:37 +0000 Received: by mail-yw0-f195.google.com with SMTP id u62so8926756ywe.3 for ; Wed, 18 May 2016 20:31:34 -0700 (PDT) In-Reply-To: <20160517210843.GD7179@char.us.oracle.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Errors-To: xen-devel-bounces@lists.xen.org Sender: "Xen-devel" To: Konrad Rzeszutek Wilk , Lars Kurth Cc: James McKenzie , sstabellini@kernel.org, Wei Liu , Ross Philipson , Andrew Cooper , openxt@googlegroups.com, steve@zentific.com, George Dunlap , Rich Persaud , Jan Beulich , Anthony PERARD , Xen-devel , Daniel De Graaf List-Id: xen-devel@lists.xenproject.org This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --===============0226877314483608572== Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="bfhJ5oJ9AVPgfQvVLDufONW7gQNXwQWbO" This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --bfhJ5oJ9AVPgfQvVLDufONW7gQNXwQWbO Content-Type: multipart/mixed; boundary="8xX0Sno7otvdoLSigwnle0EO31Ev0A0w4" From: Doug Goldstein To: Konrad Rzeszutek Wilk , Lars Kurth Cc: Daniel De Graaf , Andrew Cooper , Xen-devel , George Dunlap , Wei Liu , sstabellini@kernel.org, Anthony PERARD , Rich Persaud , openxt@googlegroups.com, Jan Beulich , Ross Philipson , James McKenzie , steve@zentific.com Message-ID: Subject: Re: [Hackathon 16] Notes from Security Session References: <5715F43E.7090503@cardoe.com> <5715F640.1070206@citrix.com> <20160425183229.GB13411@char.us.oracle.com> <571E7524.8070005@tycho.nsa.gov> <1445CEA7-78E1-428B-BD7C-757B2B8EB684@gmail.com> <20160517210843.GD7179@char.us.oracle.com> In-Reply-To: <20160517210843.GD7179@char.us.oracle.com> --8xX0Sno7otvdoLSigwnle0EO31Ev0A0w4 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 extens= ively and also documenting XSM and can provide some user perspective=20 >> Lars >> >>> On 25 Apr 2016, at 20:51, Daniel De Graaf wro= te: >>> >>> 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. >>> >>> [...] >>>>>>> =3D=3D=3D Enabling XSM By default =3D=3D=3D >>>>>>> Andrew: There are some issues which we need to work through; a lo= t 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 collabo= ratively 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 propo= se 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 compi= led >>>>>> 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 i= n and >>>>>> if you provided another policy it would be used instead or you cou= ld >>>>>> late load a replacement policy. Basically filling the gap of turni= ng on >>>>>> XSM and having a system less secure than XSM off until you develop= ed >>>>>> 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, i= t >>> would need either a script or a careful invocation of objcopy to conv= ert >>> the policy output to an array in initdata, and then that policy would= be >>> used if the bootloader one is not present. >=20 > 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. >=20 >>> >>> 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= =2E >>> >>> The first two bullets should be true with the current policy. The thi= rd >>> needs to be more precisely defined: any operation on a group it >>> controls, or limited operations (such as adjusting memory size) on al= l >>> guests? The latter will probably need a custom policy (module) for >>> exactly what the control domain does. >=20 > 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. >=20 > 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=3DBOOL" parameter apply that labe= l over domU_t but right now its just done through "seclabel". I can post what I've got as a RFC. --=20 Doug Goldstein --8xX0Sno7otvdoLSigwnle0EO31Ev0A0w4-- --bfhJ5oJ9AVPgfQvVLDufONW7gQNXwQWbO Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0 iQJ8BAEBCgBmBQJXPTOSXxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRBNTM5MEQ2RTNFMTkyNzlCNzVDMzIwOTVB MkJDMDNEQzg3RUQxQkQ0AAoJEKK8A9yH7RvUQ/MQAI5T2nCSBQF5YnF95NruBKS3 2ydNOP82a4/D/rNTXFyyf1ZWqorImLlAX4deFKdAF2i0z0bi9zcOCYHcG7hU98EJ oMuiZhfczdl6lp3bKsyjfNKHV/gWT+4PfQe7rNNeqoDvKeBknL++d5wpMUizak6H PTh1ankpNCVgWxsFOb81ce0gi07U5mQVu3eK+u+/N4a0Fo5YiI/IyXSfvx9sbiak ppuQfflMV42WA5VXthGQ/U+PVgO6Xrr6PFB9CEX8/KIMQQpKM1rQiL5sqoKsEupV UmM9DOJTYQhZ1cfVmheJWy0zl6yT8PxVKdMd0/L5sB+MU4U0mLbveYd+JlHWkIKn er4sdvjZDa+ktHhUgaTVbq/8BXHYc2Q6flfyU5yvRaR0saWnzGuYfEm2CN6yPK3j sg4MsSOQ1T8xceTrLEMSO0ivNa+WUw4RfXfAXqz3HhW3rJhOs+uTK0bkJL7CR3/j 1WkqIBN7uQqNHX3CITyBKaJLZd26piBrFGEcrOe+wd+dAIxWWL78Xa9sGF3C2hJa LFH+1ofkxYv/XpBg9ZIDLoH7U57PjZIwNrmfJaJxAgAbEyeP4sSBE6I3Chphiiv1 DJkDBWcT0xr/DMew7nX2V/20/nVCkRIBCCkzxzB5NsWhlM4h1/5vk1e5ONQzNi7u nE+1iSYJN0wDo+977/NP =uuY/ -----END PGP SIGNATURE----- --bfhJ5oJ9AVPgfQvVLDufONW7gQNXwQWbO-- --===============0226877314483608572== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KWGVuLWRldmVs IG1haWxpbmcgbGlzdApYZW4tZGV2ZWxAbGlzdHMueGVuLm9yZwpodHRwOi8vbGlzdHMueGVuLm9y Zy94ZW4tZGV2ZWwK --===============0226877314483608572==--