Re: [PATCH v3 11/11] smack: documentation for the Smack namespace

["Serge E. Hallyn" <serge@hallyn.com>]

On Fri, Jul 24, 2015 at 12:04:45PM +0200, Lukasz Pawelczyk wrote:
> +--- Design ideas ---
> +
> +"Smack namespace" is rather "Smack labels namespace" as not the whole
> +MAC is namespaced, only the labels. There is a great analogy between
> +Smack labels namespace and the user namespace part that remaps UIDs.
> +
> +The idea is to create a map of labels for a namespace so the namespace
> +is only allowed to use those labels. Smack rules are always the same
> +as in the init namespace (limited only by what labels are mapped) and
> +cannot be manipulated from the child namespace. The map is actually
> +only for labels' names. The underlying structures for labels remain
> +the same. The filesystem also stores the "unmapped" labels from the
> +init namespace.
> +
> +Let's say we have those labels in the init namespace:
> +label1
> +label2
> +label3
> +
> +and those rules:
> +label1 label2 rwx
> +label1 label3 rwx
> +label2 label3 rwx
> +
> +We create a map for a namespace:
> +label1 -> mapped1
> +label2 -> mapped2
> +
> +This means that 'label3' is completely invisible in the namespace. As if
> +it didn't exist. All the rules that include it are ignored.
> +
> +Effectively in the namespace we have only one rule:
> +mapped1 mapped2 rwx
> +
> +Which in reality is:
> +label1 label2 rwx
> +
> +All requests to access an object with a 'label3' will be denied. If it
> +ever comes to a situation where 'label3' would have to be printed
> +(e.g. reading an exec or mmap label from a file to which we have
> +access) then huh sign '?' will be printed instead.
> +
> +All the operations in the namespace on the remaining labels will have
> +to be performed using their mapped names. Things like changing own
> +process's label, changing filesystem label. Labels will also be
> +printed with their mapped names.
> +
> +You cannot import new labels in a namespace. Every operation that
> +would do so in an init namespace will return an error in the child
> +namespace. You cannot assign an unmapped or not existing label to an
> +object. You can only operate on labels that have been explicitly
> +mapped.
> +
> +
> +--- Capabilities ---
> +
> +Enabling Smack related capabilities (CAP_MAC_ADMIN and
> +CAP_MAC_OVERRIDE) is main goal of Smack namespace, so it can work
> +properly in the container. And those capabilities do work to some
> +extent. In several places where capabilities are checked compatibility
> +with Smack namespace has been introduced. Capabilities are of course
> +limited to operate only on mapped labels.
> +
> +CAP_MAC_OVERRIDE works fully, will allow you to ignore Smack access
> +rules, but only between objects that have labels mapped. So in the
> +example above having this CAP will allow e.g. label2 to write to
> +label1, but will not allow any access to label3.

(Sorry it took me this long to get to reading, and thanks for working
on this)

Oh my.  All this is not at all what I'd expected :)

Is there rationale for these decisions?  Hm, I guess it really is
following the user_ns design, but the huge difference is that the
user_ns is partitioning an already-enumerated set of kuids.  The
smack labels are inherently different.

In containers, something we'd really like to be able to do is:

Create a new container.  Just run it as label 'c1'.  Inside the
container, let the admin install mysql from a package which assigns
type 'mysqld', protecting the rest of the container from mysql.
Without the host admin doing anything.

Normally the way I think of implementing something like this would be
to allow the host to say "c1 is to be namespaceable."  Then on a userns
unshare, if the task is in c1, it gets transitioned into the ns.  Then the
container sees c1 as _ (or whatever).  It can create 'mysql' which is
actually 'c1.mysql' on the host, and it can create and override rules
to c1.*.

Also, allowing CAP_MAC_OVERRIDE in this way seems overly dangerous.
If there were rules defined by the container, then I'd expect those to
be overrideable - but not all rules pertaining to all labels mapped
into the container.  But I guess based on  your envisioned usage (where
I assume 'label1' is meant to *only* be used for that container) it
might be ok.

thanks,
-serge