Re: [Xen-devel] XSM permissive by default.

[Daniel De Graaf <dgdegra@xxxxxxxxxxxxx>]

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
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel