Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic
From: Eric W. Biederman <hidden>
Date: 2016-12-08 05:16:59
Also in:
lkml
"Serge E. Hallyn" [off-list ref] writes:
On Thu, Dec 08, 2016 at 05:43:09PM +1300, Eric W. Biederman wrote:quoted
"Serge E. Hallyn" [off-list ref] writes:quoted
Root in a user ns cannot be trusted to write a traditional security.capability xattr. If it were allowed to do so, then any unprivileged user on the host could map his own uid to root in a namespace, write the xattr, and execute the file with privilege on the host. This patch introduces v3 of the security.capability xattr. It builds a vfs_ns_cap_data struct by appending a uid_t rootid to struct vfs_cap_data. This is the absolute uid_t (i.e. the uid_t in init_user_ns) of the root id (uid 0 in a namespace) in whose namespaces the file capabilities may take effect. When a task in a user ns (which is privileged with CAP_SETFCAP toward that user_ns) asks to write v2 security.capability, the kernel will transparently rewrite the xattr as a v3 with the appropriate rootid. Subsequently, any task executing the file which has the noted kuid as its root uid, or which is in a descendent user_ns of such a user_ns, will run the file with capabilities. If a task writes a v3 security.capability, then it can provide a uid (valid within its own user namespace, over which it has CAP_SETFCAP) for the xattr. The kernel will translate that to the absolute uid, and write that to disk. After this, a task in the writer's namespace will not be able to use those capabilities, but a task in a namespace where the given uid is root will. Only a single security.capability xattr may be written. A task may overwrite the existing one so long as it was written by a user mapped into his own user_ns over which he has CAP_SETFCAP. This allows a simple setxattr to work, allows tar/untar to work, and allows us to tar in one namespace and untar in another while preserving the capability, without risking leaking privilege into a parent namespace.Any chance of a singed-off-by?Yes, sorry, Stéphane had pointed out that I'd apparently forgotten to do -s. Do you want me to resend the whole shebang, or does Signed-off-by: Serge Hallyn <redacted> suffice? (My previous iterations did have it fwiw so I don't think I could legally disavow it now :)
That should be good enough. I just wanted to make certain it existed somewhere. The whole inode->i_op->getxattr reference was also a bit of a problem as that method was removed in 4.9-rc1 but otherwise things are looking reasonable. Thank you, Eric