From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: 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: Thu, 17 Sep 2015 14:45:54 -0400 Message-ID: <20150917184554.GA20952@x230.dumpdata.com> References: <1442437276-2620-1-git-send-email-konrad.wilk@oracle.com> <1442437276-2620-6-git-send-email-konrad.wilk@oracle.com> <55F9E206.6060508@citrix.com> <55F9EDA8.1010206@citrix.com> <55FA60A9.8060202@amazon.com> <55FA8964.3010602@citrix.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1ZceCf-0004yY-0K for xen-devel@lists.xenproject.org; Thu, 17 Sep 2015 18:46:41 +0000 Content-Disposition: inline In-Reply-To: <55FA8964.3010602@citrix.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Andrew Cooper , dgdegra@tycho.nsa.gov, ian.jackson@eu.citrix.com, wei.liu2@citrix.com Cc: elena.ufimtseva@oracle.com, hanweidong@huawei.com, Martin Pohlack , 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 , fanhenglong@huawei.com List-Id: xen-devel@lists.xenproject.org . 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. > * 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