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