Re: [PATCH v2 0/7] Smack namespace

[Stephen Smalley <sds@tycho.nsa.gov>]

On 05/25/2015 08:32 AM, 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.

How do you achieve that without introducing additional hooks or
reworking the current hooks in the setxattr code path?  At present, the
security module is allowed to rewrite getxattr requests on the
security.* namespace but it isn't allowed to do that for setxattr, so if
the process invokes setxattr with a mapped label, then it will be the
mapped label that gets passed to the filesystem implementation, not the
unmapped label.  The security module may internally store it in unmapped
form and may even return that upon getxattr() calls, but if you then
reboot the system and later fetch from the filesystem, it will get the
mapped label value.

> --- Usage ---
> 
> Smack namespace is written using LSM hooks inside user namespace. That
> means it's connected to it.
> 
> To create a new Smack namespace you need to unshare() user namespace
> as usual. If that is all you do though, than there is no difference to
> what is now. To activate the Smack namespace you need to fill the
> labels' map. It is in a file /proc/$PID/smack_map.

This should be /proc/$PID/attr/label_map or similar, modeled after the
existing /proc/$PID/attr/current and similar nodes.  Then it isn't
module-specific and can be reused for other modules.

> Writing to the map file is not disabled after the first write as it is
> in uid_map. For Smack we have no means to map ranges of labels, hence
> it can really be advantageous to be able to expand the map later
> on. But you can only add to the map. You cannot remove already mapped
> labels. You cannot change the already existing mappings. Also mappings
> has to be 1-1. All requests to create a map where either the unmapped
> or the mapped label already exists in the map will be denied.

Isn't it a concern that I can then add additional labels to the mapping
for which I am not authorized?  Or is this mitigated by the fact that I
cannot alter the rules?  What about the situation for the predefined
labels in Smack - are you assuming that they will always be mapped up
front in the mapping file?