Re: [PATCH 8/8] xl.pod.1: improve documentation of FLASK commands

[Daniel De Graaf <dgdegra@tycho.nsa.gov>]

On 12/15/2011 11:46 AM, Stefano Stabellini wrote:
> On Tue, 13 Dec 2011, Daniel De Graaf wrote:
>> +=head2 FLASK
>> +
>> +=over 4
>> +
>> +=item B<getenforce>
>> +
>> +Determine if the FLASK security module is loaded and enforcing its policy.
>> +
>> +=item B<setenforce> I<1|0|Enforcing|Permissive>
>> +
>> +Enable or disable enforcing of the FLASK access controls. The default is
>> +permissive and can be changed using the flask_enforcing option on the
>> +hypervisor's command line.
>> +
>> +=item B<loadpolicy> I<policy-file>
>> +
>> +Load FLASK policy from the given policy file. The initial policy is provided to
>> +the hypervisor as a multiboot module; this command allows runtime updates to the
>> +policy. Loading new security policy will reset runtime changes to device labels.
> 
> Thanks for the patch!
> Since we are trying to improve the documentation for Xl, would you be up
> for writing a couple of more lines explaining why people might want to
> use XSM?

FLASK is a security framework that defines a mandatory access control policy
providing fine-grained controls over Xen domains, allowing the policy writer
to define what interactions between domains, devices, and the hypervisor are
permitted. Some example of what you can do using XSM/FLASK:
 - Prevent two domains from communicating via event channels or grants
 - Control which domains can use device passthrough (and which devices)
 - Restrict or audit operations performed by privileged domains
 - Prevent a privileged domain from arbitrarily mapping pages from other domains

Note that some of these examples require dom0 disaggregation to be useful, since
the domain build process requires the ability to write to the new domain's memory.

> In case there are some parameters to be used in the VM config
> file, could you please write a simple text file, like
> docs/misc/xl-network-configuration.markdown, describing which ones they
> are?

There is only one domain configuration parameter (the security label), which
I'm not sure is enough to justify its own file. If using the example policy,
"seclabel='system_u:system_r:domU_t'" would be used for PV domains, while
"seclabel='system_u:system_r:domHU_t'" would be used for HVM domains. A more
complex policy may have a different type for each domain.

It would be better to refer to existing SELinux documentation for an
explanation of the meanings of system_u, system_r, domU_t, and possible MLS
labels. For simple policies, the user and role portions of the label will
be unused and will always be "system_u:system_r".

> Finally it would be great if you could submit, as a separate patch, an
> example policy file that we can keep under tools/examples/ or docs/misc
> for everybody to use.

There is already an example policy file in tools/flask/policy/policy/modules/xen/xen.te
although it will likely require additional rules to be run in enforcing mode.
The policy is not built as part of the normal build process, but it can be
built by running "make -C tools/flask/policy". If using Fedora 16 (or systems
with a checkpolicy version >24) the Makefile will need to be adjusted to
produce policy version 24 which is the latest version supported by Xen.

-- 
Daniel De Graaf
National Security Agency