"Serge E. Hallyn" <serge@xxxxxxxxxx> writes: > Quoting Eric W. Beiderman (ebiederm@xxxxxxxxxxxx): >> From: Eric W. Biederman <ebiederm@xxxxxxxxxxxx> >> > > Oh, perhaps this is the right place in the thread to discuss the issue of > what to do with file capabilities? I'm ok waiting until the next iteration > to even discuss it, so long as we start by refusing setting of fcaps by > any task not in init_user_ns. For now we do refuse all callers in the init_user_ns because that path is protected by a capable and not an ns_capable call. And as a general policy I have pushed all of the changes from capable to ns_capable out till after we get these other user namespace bits so we can get the patches reviewed so hopefully don't enable something that is not safe. Let's just note here that when we ever get a filesystem mounted in something other than the init_user_ns or otherwise allow file capabilities that do not belong to the init_user_ns we need to an additional exec check to avoid a security issue for processes in the init_user_ns using those credentials. The other direction the init_user_ns setting file caps on a file and use using them in a child namespace seems safe, and practical because of the way we handle capabilities. Aka if you have a capability in an outer user namespace you also have it in a child user namespace. Which means a file cap exec today will give you just the capabilities in the child user namespace. Something else to think about when we reach filesystems mounted in different user namespaces (aka unprivileged mounts) are security labels on files in different user namespaces. Not any kind of immediate concern but something we may have to handle eventually. 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
