[PATCH v2 0/7] Smack namespace

[Stephen Smalley]

On 05/26/2015 12:27 PM, Lukasz Pawelczyk wrote:
> Hi,
> 
> Thanks for taking the interest and commenting on this.
> Replies below.
> 
> 
> On wto, 2015-05-26 at 10:35 -0400, Stephen Smalley wrote:
>> 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.
> 
> I call the inode operation by hand in the post_setxattr.
> 
> The label will effectively be set twice, which is not ideal, but there
> is no other option right now without reworking the hooks as you said.
> 
> This shouldn't really be a problem because the Smack operations will not
> use the filesystem label (even when it's set incorrectly for a moment)
> but an already initialized smack_known structure for this inode that has
> all the values filled in properly.
> 
> The only attack vector I can think of is hard rebooting the machine in a
> way that mapped label is really saved in the filesystem before the
> unmapped will have a chance. Should I be worried about that? This sounds
> a little unreal.

If it were my security module, I would be worried about it.  Even aside
from maliciously induced failure, you are leaving yourself open to
inconsistencies arising upon crashes.  I would suggest modifying the
setxattr hook so that the security module can override the original
value/size pair with its own definition before it is passed to the inode
operation.  There is already precedent in that security modules are
allowed to override the value/size returned by getxattr for security.*,
so this just makes them fully parallel.