Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1538307
| From | ebiederm@xmission.com (Eric W. Biederman) |
|---|---|
| Newsgroups | linux.kernel |
| Subject | Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic |
| Date | 2016-12-08 05:50 +0100 |
| Message-ID | <sLYOB-1pF-7@gated-at.bofh.it> (permalink) |
| References | <sFfAS-6E4-3@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
"Serge E. Hallyn" <serge@hallyn.com> writes: > 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? Eric
Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread
Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-08 05:50 +0100
Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic "Serge E. Hallyn" <serge@hallyn.com> - 2016-12-08 06:00 +0100
Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-08 06:20 +0100
Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-09 09:10 +0100
Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic "Serge E. Hallyn" <serge@hallyn.com> - 2016-12-09 14:50 +0100
Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-09 22:50 +0100
Re: [PATCH RFC] user-namespaced file capabilities - now with even more magic ebiederm@xmission.com (Eric W. Biederman) - 2016-12-10 00:40 +0100
csiph-web