xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Andrew Cooper <andrew.cooper3@citrix.com>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	dgdegra@tycho.nsa.gov, ian.jackson@eu.citrix.com,
	wei.liu2@citrix.com
Cc: elena.ufimtseva@oracle.com, hanweidong@huawei.com,
	Martin Pohlack <mpohlack@amazon.de>,
	jbeulich@suse.com, john.liuqiming@huawei.com,
	paul.voccio@rackspace.com, daniel.kiper@oracle.com,
	major.hayden@rackspace.com, liuyingdong@huawei.com,
	aliguori@amazon.com, xen-devel@lists.xenproject.org,
	lars.kurth@citrix.com, steven.wilson@rackspace.com,
	ian.campbell@citrix.com, peter.huangpeng@huawei.com,
	msw@amazon.com, xiantao.zxt@alibaba-inc.com,
	rick.harris@rackspace.com, boris.ostrovsky@oracle.com,
	josh.kearney@rackspace.com, jinsong.liu@alibaba-inc.com,
	amesserl@rackspace.com, Martin Pohlack <mpohlack@amazon.com>,
	fanhenglong@huawei.com
Subject: Re: Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: [PATCH v1 5/5] xsplice: Use ld-embedded build-ids
Date: Fri, 18 Sep 2015 12:40:46 +0100	[thread overview]
Message-ID: <55FBF83E.50301@citrix.com> (raw)
In-Reply-To: <20150917184554.GA20952@x230.dumpdata.com>

On 17/09/15 19:45, Konrad Rzeszutek Wilk wrote:
> . snip..
>>>>>> The build id of the current running hypervisor should belong in the
>>>>>> xeninfo hypercall.  It is not specific to xsplice.
>>>>> However in the previous reviews it was pointed out that it should only be accessible to dom0.
>>>>>
>>>>> Or to any domains as long as the XSM allows (and is turned on) - so not the default dummy one.
>>>>>
>>>>> That is a bit of 'if' extra complexity which I am not sure is worth it?
>>>> DomU can already read the build information such as changeset, compile
>>>> time, etc.  Build-id is no more special or revealing.
>>> I would take this as an argument *against* giving DomU access to those
>>> pieces of information in details and not as an argument for
>>> *additionally* giving it access to build-id.
>>>
>>> With build-id we have the chance to shape a not-yet-established API and
>>> I would like to follow the Principle of least privilege wherever it
>>> makes sense.
>>>
>>> To reach a similar security level with the existing API, it might make
>>> sense to limit DomU access to compile date, compile time, compiled by,
>>> compiled domain, compiler version and command line details, xen extra
>>> version, and xen changeset.  Basically anything that might help DomUs to
>>> uniquely identify a Xen build.
>>>
>>> The approach can not directly drop access to those fields, as that would
>>> break an existing API, but it could restrict the detail level handed out
>>> to DomU.
>> These are all valid arguments to be made, but please lets fix the issue
>> properly rather than hacking build-id on the side of an unrelated component.
>>
>> From my point of view, the correct course of action is this:
>>
>> * Split the current XSM model to contain separate attributes for general
>> and privileged information.
>> ** For current compatibility, all existing XENVER_* subops fall into general
>> * Apply an XSM check at the very start of the hypercall.
>> * Extend do_xen_version() to take 3 parameters.  (It is curious that it
>> didn't take a length parameter before)
>> ** This is still ABI compatible, as existing subops simply ignore the
>> parameter.
> Or we can just use 1024 bytes space the XENVER_* use.

What 1024 bytes?

Each subop currently assumes the guest handle is a pointer to an
appropriately typed structure, which puts arbitrary and unnecessary
length restrictions on items.

~Andrew

>
>> * Introduce new XENVER_build_id subop which is documented to require the
>> 3-parameter version of the hypercall.
>> ** This subop falls into straight into privileged information.
>>
>> This will introduce build-id in its correct location, with appropriate
>> restrictions.
>>
>> Moving forwards, we really should have an audit of the existing XENVER_*
>> subops.  Some are clearly safe/required for domU to read, but some such
>> as XENVER_commandline have no business being accessible.  A separate
>> argument, from the repeatable build point of view, says that compilation
>> information isn't useful at all.
>>
>> Depending on how we wish to fix the issue, we could either do a blanket
>> move of the subops into the privileged XSM catagory, or introduce a 3rd
>> "legacy privileged" category to allow the admin to control access on a
>> per-vm basis.
> CC-ing Daniel. Changing title.
>> ~Andrew

  reply	other threads:[~2015-09-18 11:40 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-16 21:01 [PATCH v1] xSplice initial foundation patches Konrad Rzeszutek Wilk
2015-09-16 21:01 ` [PATCH v1 1/5] xsplice: Design document Konrad Rzeszutek Wilk
2015-10-05 10:02   ` Jan Beulich
2015-10-05 10:28   ` Ross Lagerwall
2015-10-12 11:44     ` xsplice-build prototype (was [PATCH v1 1/5] xsplice: Design document.) Ross Lagerwall
2015-10-12 13:06       ` Konrad Rzeszutek Wilk
2015-10-12 14:20       ` Konrad Rzeszutek Wilk
2015-10-06 12:57   ` [PATCH v1 1/5] xsplice: Design document Ross Lagerwall
2015-10-27  8:08     ` Martin Pohlack
2015-10-27  8:45       ` Ross Lagerwall
2015-10-06 15:26   ` Jan Beulich
2015-10-26 12:01   ` Martin Pohlack
2015-10-26 12:10     ` Jan Beulich
2015-10-26 13:21     ` Ross Lagerwall
2015-10-26 13:55       ` Konrad Rzeszutek Wilk
2015-09-16 21:01 ` [PATCH v1 2/5] xen/xsplice: Hypervisor implementation of XEN_XSPLICE_op Konrad Rzeszutek Wilk
2015-10-02 15:06   ` Jan Beulich
2015-09-16 21:01 ` [PATCH v1 3/5] libxc: Implementation of XEN_XSPLICE_op in libxc Konrad Rzeszutek Wilk
2015-09-16 21:01 ` [PATCH v1 4/5] xen-xsplice: Tool to manipulate xsplice payloads Konrad Rzeszutek Wilk
2015-09-16 21:01 ` [PATCH v1 5/5] xsplice: Use ld-embedded build-ids Konrad Rzeszutek Wilk
2015-09-16 21:41   ` Andrew Cooper
2015-09-16 21:59     ` Konrad Rzeszutek Wilk
2015-09-16 22:31       ` Andrew Cooper
2015-09-17  6:41         ` Martin Pohlack
2015-09-17  9:35           ` Andrew Cooper
2015-09-17 18:45             ` Is: Make XENVER_* use XSM, seperate the different ops in smaller security domains. Was:Re: " Konrad Rzeszutek Wilk
2015-09-18 11:40               ` Andrew Cooper [this message]
2015-09-22 13:22                 ` Konrad Rzeszutek Wilk
2015-09-22 13:33                   ` Andrew Cooper
2015-09-22 13:45                     ` Konrad Rzeszutek Wilk
2015-09-22 16:28                       ` Daniel De Graaf
2015-09-22 16:28               ` Daniel De Graaf
2015-09-25 20:18                 ` Konrad Rzeszutek Wilk
2015-10-02 15:13   ` Jan Beulich
2015-10-02 14:48 ` [PATCH v1] xSplice initial foundation patches Konrad Rzeszutek Wilk
2015-10-09 12:46   ` Konrad Rzeszutek Wilk

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=55FBF83E.50301@citrix.com \
    --to=andrew.cooper3@citrix.com \
    --cc=aliguori@amazon.com \
    --cc=amesserl@rackspace.com \
    --cc=boris.ostrovsky@oracle.com \
    --cc=daniel.kiper@oracle.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=elena.ufimtseva@oracle.com \
    --cc=fanhenglong@huawei.com \
    --cc=hanweidong@huawei.com \
    --cc=ian.campbell@citrix.com \
    --cc=ian.jackson@eu.citrix.com \
    --cc=jbeulich@suse.com \
    --cc=jinsong.liu@alibaba-inc.com \
    --cc=john.liuqiming@huawei.com \
    --cc=josh.kearney@rackspace.com \
    --cc=konrad.wilk@oracle.com \
    --cc=lars.kurth@citrix.com \
    --cc=liuyingdong@huawei.com \
    --cc=major.hayden@rackspace.com \
    --cc=mpohlack@amazon.com \
    --cc=mpohlack@amazon.de \
    --cc=msw@amazon.com \
    --cc=paul.voccio@rackspace.com \
    --cc=peter.huangpeng@huawei.com \
    --cc=rick.harris@rackspace.com \
    --cc=steven.wilson@rackspace.com \
    --cc=wei.liu2@citrix.com \
    --cc=xen-devel@lists.xenproject.org \
    --cc=xiantao.zxt@alibaba-inc.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).