xen-devel.lists.xenproject.org archive mirror
 help / color / mirror / Atom feed
From: Doug Goldstein <cardoe@cardoe.com>
To: Daniel De Graaf <dgdegra@tycho.nsa.gov>,
	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 20:40:05 -0600	[thread overview]
Message-ID: <56E0DE85.7000805@cardoe.com> (raw)
In-Reply-To: <56E09F20.7090601@tycho.nsa.gov>


[-- Attachment #1.1.1: Type: text/plain, Size: 2101 bytes --]

On 3/9/16 4:09 PM, Daniel De Graaf wrote:
> 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?

>>>
>>> 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"?).
> 

Honestly I'm in favor of secure by default approach. Since Xen is not
built with flask by default to me the sane approach would be to default
the system to "flask=enforcing".

"flask=late" not allowing the creation of domains sounds good but what
if you're using a disaggregated dom0 with some domDs and one of them
needs to be up to fetch your policy? Just a hypothetical.

XSMs like LSMs just aren't meant to be swapped around at runtime and
like Daniel points out if go down the road of swapping to the dummy
module there could be further dragons and whose to say someone won't
look at that and put something in that allows you to switch to another
later on (yes I know there's only really 1 but I'm speaking of the
hypothetical).

-- 
Doug Goldstein


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 959 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel

  reply	other threads:[~2016-03-10  2:40 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
2016-03-10  2:40       ` Doug Goldstein [this message]
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:
  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=56E0DE85.7000805@cardoe.com \
    --to=cardoe@cardoe.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=dgdegra@tycho.nsa.gov \
    --cc=konrad.wilk@oracle.com \
    --cc=xen-devel@lists.xenproject.org \
    /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).