Re: Building MLS/MCS policy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, 2010-01-26 at 16:46 +0100, Guido Trentalancia wrote:
> Stephen,
> 
> what I propose is to add a few lines of documentation explaining the process of switching between different policy types (see the two patches below, one for load_policy and the other for the reference policy).

You should technically separate these patches into separate messages,
the first directed to selinux list and the second directed to the
refpolicy list, with your diffs preferably against the respective git
trees for the two different projects (selinux userland vs. refpolicy).
But see below first.

> diff -pru policycoreutils-2.0.77/load_policy/load_policy.8 policycoreutils-2.0.77-new/load_policy/load_policy.8
> --- policycoreutils-2.0.77/load_policy/load_policy.8    2009-11-19 23:16:03.000000000 +0100
> +++ policycoreutils-2.0.77-new/load_policy/load_policy.8        2010-01-26 16:26:11.210178317 +0100
> @@ -12,6 +12,11 @@ load_policy loads the installed policy f
>  The existing policy boolean values are automatically preserved
>  across policy reloads rather than being reset to the default
>  values in the policy file.
> +.PP
> +It should be noted that it is not possible to switch between
> +a non-MLS/MCS policy and a MLS/MCS policy or viceversa at
> +runtime. To switch between such different types of policies
> +change the SELinux configuration and reboot the kernel.
> 
>  .SH "OPTIONS"
>  .TP

- Is the user likely to look at the load_policy man page upon this
failure given that he never directly invokes load_policy but only
indirectly through a chain of make load -> semodule -> load_policy?

- Is the last sentence sufficiently clear to actually help the user
resolve the problem?  I don't think so.  If this were the semodule man
page, I'd suggest that the user pass the -n flag to suppress policy
reload and only update the policy files, thereby enabling them to then
reboot with the new policy, or to pass the -s flag with an alternate
policy store (which is what setting NAME= in the refpolicy build.conf is
doing for you) so that it doesn't try to reload and then
changing /etc/selinux/config.  But this isn't the semodule man page.

> diff -pru refpolicy-2.20091117/README refpolicy-2.20091117-new/README
> --- refpolicy-2.20091117/README 2009-07-14 14:24:46.000000000 +0200
> +++ refpolicy-2.20091117-new/README     2010-01-26 16:39:13.272185609 +0100
> @@ -267,3 +267,14 @@ refresh                    Attempts to reinsert all modul
>  xml                    Build a policy.xml from the XML included with the
>                         base policy headers and any XML in the modules in
>                         the current directory.
> +
> +5) Switching between different types of policies (e.g. from non-MLS to MLS)
> +
> +In order to switch from a non-MLS/non-MCS policy to a MLS or MCS policy
> +(and viceversa), make sure to change in build.conf not only the TYPE
> +parameter between the two policies but also the NAME parameter (just name
> +the new policy differently from the previous one). Also, after building the
> +new policy, in order to load it for the first time (and eventually install
> +custom modules), it might be necessary to reboot the kernel in permissive
> +mode (after having changed the SELinux configuration file to select the
> +new policy).

This is up to Chris, but I'd tend to put this information with the
description of TYPE under the build.conf description rather than as a
separate item.  And it could be clearer.  Note that if you leave NAME=
blank then it inherits from TYPE, and thus a mcs or mls policy
automatically gets a distinct name.

Alternatively to spending time on documenting the current limitation, it
might be more interesting to try removing the restriction from the
SELinux kernel code and investigating what needs to be done within the
kernel to enable it to be done safely.  Primarily this would mean:
- pushing the selinux_mls_enabled flag inside the policydb so that it
could be per-policydb (this is already the case in libsepol),
- in the non-MLS to MLS case, ensuring that the MLS fields of the
context for all existing entries in the sidtab are filled in with a
suitable default value, likely taken from one of the initial SIDs,
- in the MLS to non-MLS case, freeing any storage used by the MLS fields
in the context for all existing entries in the sidtab.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.

[Index of Archives]     [Selinux Refpolicy]     [Linux SGX]     [Fedora Users]     [Fedora Desktop]     [Yosemite Photos]     [Yosemite Camping]     [Yosemite Campsites]     [KDE Users]     [Gnome Users]

  Powered by Linux