Lukasz Pawelczyk <l.pawelczyk@xxxxxxxxxxx> 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 -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
