Lukasz Pawelczyk <l.pawelczyk@samsung.com> writes:

> On śro, 2015-07-15 at 16:06 -0500, Eric W. Biederman wrote:
>> 
>> I am on the fence with Lukasz Pawelczyk's patches.  Some parts I 
>> liked
>> some parts I had issues with.  As I recall one of my issues was that
>> those patches conflicted in detail if not in principle with this
>> appropach.
>> 
>> If these patches do not do a good job of laying the ground work for
>> supporting security labels that unprivileged users can set than Seth
>> could really use some feedback.  Figuring out how to properly deal 
>> with
>> the LSMs has been one of his challenges.
>
> I fail to see how those 2 are in any conflict. 

Like I said.  They don't really conflict, and actually to really support
things well for smack we probably need something like your patches.

At the same time a patch written without dealing with s_user_ns is going
to going to fail to take a lot of important details into account.

Right now after fixing the mount namespace issues the top priority is to
work through the details and get s_user_ns implemented.  By that I mean
some version of patch 1 of Seth's series.

s_user_ns fundamentally changes how the concepts are represented in the
kernel in a way that is easier to secure, and that fundamentally better
matches things.  And sigh.  This review has shown we don't quite have
all of the details worked out.

> If your approach here is to treat user ns mounted filesystem as if they
> didn't support xattrs at all then my patches don't conflict here any
> more than Smack itself already does.

The end game if people developing smack choose to play, is to figure out
how to store your unmapped labels in a filesystem contained by a
user namespace and a smack label namespace root.

> If the filesystem will get a default (e.g. by smack* mount options)
> label then this label will co-work with Smack namespaces.

A default, but I don't know if it will be smack mount options that will
give that default.  The devil is in the details and there are a lot
of details.

Eric