xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Daniel De Graaf <dgdegra@tycho.nsa.gov>
To: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>,
	Andrew Cooper <andrew.cooper3@citrix.com>
Cc: xen-devel@lists.xenproject.org
Subject: Re: XSM permissive by default.
Date: Wed, 9 Mar 2016 17:09:36 -0500	[thread overview]
Message-ID: <56E09F20.7090601@tycho.nsa.gov> (raw)
In-Reply-To: <20160309211735.GA28919@char.us.oracle.com>

On 03/09/2016 04:17 PM, Konrad Rzeszutek Wilk wrote:
> On Wed, Mar 09, 2016 at 01:24:15PM +0000, Andrew Cooper wrote:
>> On 09/03/16 01:51, Konrad Rzeszutek Wilk wrote:
>>> Hey,
>>> I was wondering if it we should change the default flask_bootparam
>>> option from permissive to disabled?
>>> The reason being is that I was startled to see that my xSplice
>>> code was able to patch the hypervisor from within an PV guest!
>>> Further testing showed that I could do 'xl debug-keys R' from
>>> within the guests. This being possible with released 4.6 if I have
>>> XSM enabled.
>>> All of this is due to the fact that I had forgotten to load the policy,
>>> but Xen just told me:
>>> Flask:  Access controls disabled until policy is loaded.
>>> which is an understatement. I somehow had expected that if no
>>> policy was loaded it would revert to the dummy one which has the
>>> same permission as the non-XSM build. Ha! What a surprise..
>>> Now that the XSM is enabled via config it becomes much more
>>> easy to enable it..
>>> Or perhaps change the code to flask so that if there are any
> s/flask/dummy/
>>> errors loading the policy it uses the dummy one?
>> By the looks of it, "permissive" shouldn't be an available option at all.

Permissive is meant for developing (or debugging) a disaggregated system,
where the restrictions on non-dom0 would also break the system.  However,
I agree that it needs to be harder to end up in this mode by accident.

The simplest solution in my opinion is to change the boot parameter to
default to "flask=enforcing", which will fail the boot if a policy is
not available prior to dom0 creation.  This would require any setup
where the policy is loaded from userspace to explicitly specify
"flask=late", whereas they can currently get away with no parameter.

Another solution would be to default to "flask=late" and either deny the
creation of domains if a policy is not present, or automatically revert
to the dummy module on domain creation with no loaded policy.  The latter
probably deserves a different name ("flask=auto"?).

>> If a misconfiguration occurs, the behaviour should revert back to the
>> current "dom0 all powerful, everything else unprivileged" state which
>> currently exists without XSM.
> Looking deeper in the code I believe it should be possible to swap
> from the 'flask_ops' to the 'dummy_ops' (which is what you have without
> XSM) if there is a failure during booting to load the policy file
> (or the person simply forgot to include it).
> However it was not clear to me whether changing the ops from dummy_ops
> to flask_ops during runtime (When the policy being loaded) would work.
> It looks like it should be possible as FLASK_DISABLE does it..

The main issue with starting with dummy and then switching to FLASK is
that any domains created while using the dummy policy won't have
flask_domain_alloc_security called to populate domain->ssid, and the
rest of the flask code relies on this being non-NULL. The same would
be true for event channels, but inlining the field to save space makes
that a non-issue.

> Or whether one can FLASK_LOAD if the ops are dummy_ops instead
> of flask_ops.

Right, the flask_op hypercall is also disconnected in the dummy module.

> I will try to spin out a patch for this next week.
>> ~Andrew

Daniel De Graaf
National Security Agency

Xen-devel mailing list

  reply	other threads:[~2016-03-09 22:09 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-09  1:51 XSM permissive by default Konrad Rzeszutek Wilk
2016-03-09  2:11 ` Doug Goldstein
2016-03-09 13:24 ` Andrew Cooper
2016-03-09 21:17   ` Konrad Rzeszutek Wilk
2016-03-09 22:09     ` Daniel De Graaf [this message]
2016-03-10  2:40       ` Doug Goldstein
2016-03-10 17:10         ` Konrad Rzeszutek Wilk
2016-03-10 17:34           ` Doug Goldstein
2016-03-10 17:44           ` Andrew Cooper
2016-03-10 18:30           ` [PATCH] flask: change default state to enforcing Daniel De Graaf
2016-03-10 19:12             ` Konrad Rzeszutek Wilk
2016-03-10 19:37               ` Daniel De Graaf
2016-03-15 14:48               ` Anshul Makkar
2016-03-11  9:07             ` Jan Beulich
2016-03-11 14:58               ` Konrad Rzeszutek Wilk
2016-03-11 15:39               ` Daniel De Graaf
2016-03-11 15:43                 ` Jan Beulich
2016-03-11 15:51                   ` Daniel De Graaf
2016-04-04 17:12           ` XSM permissive by default Ian Jackson
2016-04-05  8:03             ` Jan Beulich

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:

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

  git send-email \
    --in-reply-to=56E09F20.7090601@tycho.nsa.gov \
    --to=dgdegra@tycho.nsa.gov \
    --cc=andrew.cooper3@citrix.com \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xenproject.org \


* 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).