From: Christian Brauner <hidden> Date: 2020-02-18 14:35:36
Hey everyone,
This is v3 after (off- and online) discussions with Jann the following
changes were made:
- To handle nested user namespaces cleanly, efficiently, and with full
backwards compatibility for non fsid-mapping aware workloads we only
allow writing fsid mappings as long as the corresponding id mapping
type has not been written.
- Split the patch which adds the internal ability in
kernel/user_namespace to verify and write fsid mappings into tree
patches:
1. [PATCH v3 04/25] fsuidgid: add fsid mapping helpers
patch to implement core helpers for fsid translations (i.e.
make_kfs*id(), from_kfs*id{_munged}(), kfs*id_to_k*id(),
k*id_to_kfs*id()
2. [PATCH v3 05/25] user_namespace: refactor map_write()
patch to refactor map_write() in order to prepare for actual fsid
mappings changes in the following patch. (This should make it
easier to review.)
3. [PATCH v3 06/25] user_namespace: make map_write() support fsid mappings
patch to implement actual fsid mappings support in mape_write()
- Let the keyctl infrastructure only operate on kfsid which are always
mapped/looked up in the id mappings similar to what we do for
filesystems that have the same superblock visible in multiple user
namespaces.
This version also comes with minimal tests which I intend to expand in
the future.
From pings and off-list questions and discussions at Google Container
Security Summit there seems to be quite a lot of interest in this
patchset with use-cases ranging from layer sharing for app containers
and k8s, as well as data sharing between containers with different id
mappings. I haven't Cced all people because I don't have all the email
adresses at hand but I've at least added Phil now. :)
This is the implementation of shiftfs which was cooked up during lunch at
Linux Plumbers 2019 the day after the container's microconference. The
idea is a design-stew from Stéphane, Aleksa, Eric, and myself (and by
now also Jann.
Back then we all were quite busy with other work and couldn't really sit
down and implement it. But I took a few days last week to do this work,
including demos and performance testing.
This implementation does not require us to touch the VFS substantially
at all. Instead, we implement shiftfs via fsid mappings.
With this patch, it took me 20 mins to port both LXD and LXC to support
shiftfs via fsid mappings.
For anyone wanting to play with this the branch can be pulled from:
https://github.com/brauner/linux/tree/fsid_mappingshttps://gitlab.com/brauner/linux/-/tree/fsid_mappingshttps://git.kernel.org/pub/scm/linux/kernel/git/brauner/linux.git/log/?h=fsid_mappings
The main use case for shiftfs for us is in allowing shared writable
storage to multiple containers using non-overlapping id mappings.
In such a scenario you want the fsids to be valid and identical in both
containers for the shared mount. A demo for this exists in [3].
If you don't want to read on, go straight to the other demos below in
[1] and [2].
People not as familiar with user namespaces might not be aware that fsid
mappings already exist. Right now, fsid mappings are always identical to
id mappings. Specifically, the kernel will lookup fsuids in the uid
mappings and fsgids in the gid mappings of the relevant user namespace.
With this patch series we simply introduce the ability to create fsid
mappings that are different from the id mappings of a user namespace.
The whole feature set is placed under a config option that defaults to
false.
In the usual case of running an unprivileged container we will have
setup an id mapping, e.g. 0 100000 100000. The on-disk mapping will
correspond to this id mapping, i.e. all files which we want to appear as
0:0 inside the user namespace will be chowned to 100000:100000 on the
host. This works, because whenever the kernel needs to do a filesystem
access it will lookup the corresponding uid and gid in the idmapping
tables of the container.
Now think about the case where we want to have an id mapping of 0 100000
100000 but an on-disk mapping of 0 300000 100000 which is needed to e.g.
share a single on-disk mapping with multiple containers that all have
different id mappings.
This will be problematic. Whenever a filesystem access is requested, the
kernel will now try to lookup a mapping for 300000 in the id mapping
tables of the user namespace but since there is none the files will
appear to be owned by the overflow id, i.e. usually 65534:65534 or
nobody:nogroup.
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping exists,
the corresponding files will have correct ownership.
A note on proc (and sys), the proc filesystem is special in sofar as it
only has a single superblock that is (currently but might be about to
change) visible in all user namespaces (same goes for sys). This means
it has special semantics in many ways, including how file ownership and
access works. The fsid mapping implementation does not alter how proc
(and sys) ownership works. proc and sys will both continue to lookup
filesystem access in id mapping tables.
When Writing fsid mappings the same rules apply as when writing id
mappings so I won't reiterate them here. The limit of fs id mappings is
the same as for id mappings, i.e. 340 lines.
# Performance
Back when I extended the range of possible id mappings to 340 I did
performance testing by booting into single user mode, creating 1,000,000
files to fstat()ing them and calculated the mean fstat() time per file.
(Back when Linux was still fast. I won't mention that the stat
numbers have (thanks microcode!) doubled since then...)
I did the same test for this patchset: one vanilla kernel, one kernel
with my fsid mapping patches but CONFIG_USER_NS_FSID set to n and one
with fsid mappings patches enabled. I then ran the same test on all
three kernels and compared the numbers. The implementation does not
introduce overhead. That's all I can say. Here are the numbers:
| vanilla v5.5 | fsid mappings | fsid mappings | fsid mappings |
| | disabled in Kconfig | enabled in Kconfig | enabled in Kconfig |
| | | and unset for all | and set for all |
| | | test cases | test cases |
-------------|--------------|---------------------|--------------------|--------------------|
0 mappings | 367 ns | 365 ns | 365 ns | N/A |
1 mappings | 362 ns | 367 ns | 363 ns | 363 ns |
2 mappings | 361 ns | 369 ns | 363 ns | 364 ns |
3 mappings | 361 ns | 368 ns | 366 ns | 365 ns |
5 mappings | 365 ns | 368 ns | 363 ns | 365 ns |
10 mappings | 391 ns | 388 ns | 387 ns | 389 ns |
50 mappings | 395 ns | 398 ns | 401 ns | 397 ns |
100 mappings | 400 ns | 405 ns | 399 ns | 399 ns |
200 mappings | 404 ns | 407 ns | 430 ns | 404 ns |
300 mappings | 492 ns | 494 ns | 432 ns | 413 ns |
340 mappings | 495 ns | 497 ns | 500 ns | 484 ns |
# Demos
[1]: Create a container with different id and fsid mappings.
https://asciinema.org/a/300233
[2]: Create a container with id mappings but without fsid mappings.
https://asciinema.org/a/300234
[3]: Share storage between multiple containers with non-overlapping id
mappings.
https://asciinema.org/a/300235
Thanks!
Christian
Christian Brauner (25):
user_namespace: introduce fsid mappings infrastructure
proc: add /proc/<pid>/fsuid_map
proc: add /proc/<pid>/fsgid_map
fsuidgid: add fsid mapping helpers
user_namespace: refactor map_write()
user_namespace: make map_write() support fsid mappings
proc: task_state(): use from_kfs{g,u}id_munged
cred: add kfs{g,u}id
fs: add is_userns_visible() helper
namei: may_{o_}create(): handle fsid mappings
inode: inode_owner_or_capable(): handle fsid mappings
capability: privileged_wrt_inode_uidgid(): handle fsid mappings
stat: handle fsid mappings
open: handle fsid mappings
posix_acl: handle fsid mappings
attr: notify_change(): handle fsid mappings
commoncap: cap_bprm_set_creds(): handle fsid mappings
commoncap: cap_task_fix_setuid(): handle fsid mappings
commoncap: handle fsid mappings with vfs caps
exec: bprm_fill_uid(): handle fsid mappings
ptrace: adapt ptrace_may_access() to always uses unmapped fsids
devpts: handle fsid mappings
keys: handle fsid mappings
sys: handle fsid mappings in set*id() calls
selftests: add simple fsid mapping selftests
fs/attr.c | 23 +-
fs/devpts/inode.c | 7 +-
fs/exec.c | 25 +-
fs/inode.c | 7 +-
fs/namei.c | 36 +-
fs/open.c | 16 +-
fs/posix_acl.c | 17 +-
fs/proc/array.c | 5 +-
fs/proc/base.c | 34 ++
fs/stat.c | 48 +-
include/linux/cred.h | 4 +
include/linux/fs.h | 5 +
include/linux/fsuidgid.h | 122 +++++
include/linux/stat.h | 1 +
include/linux/user_namespace.h | 10 +
init/Kconfig | 11 +
kernel/capability.c | 10 +-
kernel/ptrace.c | 4 +-
kernel/sys.c | 106 +++-
kernel/user.c | 22 +
kernel/user_namespace.c | 517 ++++++++++++++++--
security/commoncap.c | 35 +-
security/keys/key.c | 2 +-
security/keys/permission.c | 4 +-
security/keys/process_keys.c | 6 +-
security/keys/request_key.c | 10 +-
security/keys/request_key_auth.c | 2 +-
tools/testing/selftests/Makefile | 1 +
.../testing/selftests/user_namespace/Makefile | 11 +
.../selftests/user_namespace/test_fsid_map.c | 511 +++++++++++++++++
30 files changed, 1461 insertions(+), 151 deletions(-)
create mode 100644 include/linux/fsuidgid.h
create mode 100644 tools/testing/selftests/user_namespace/Makefile
create mode 100644 tools/testing/selftests/user_namespace/test_fsid_map.c
base-commit: bb6d3fb354c5ee8d6bde2d576eb7220ea09862b9
--
2.25.0
From: Christian Brauner <hidden> Date: 2020-02-18 14:35:39
Switch privileged_wrt_inode_uidgid() to lookup fsids in the fsid mappings. If
no fsid mappings are setup the behavior is unchanged, i.e. fsids are looked up
in the id mappings.
Filesystems that share a superblock in all user namespaces they are mounted in
will retain their old semantics even with the introduction of fsid mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
kernel/capability.c | 10 ++++++++--
1 file changed, 8 insertions(+), 2 deletions(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:35:53
Switch notify_change() to lookup fsids in the fsid mappings. If no fsid
mappings are setup the behavior is unchanged, i.e. fsids are looked up in the
id mappings.
Filesystems that share a superblock in all user namespaces they are mounted in
will retain their old semantics even with the introduction of fsid mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
fs/attr.c | 23 +++++++++++++++++------
1 file changed, 17 insertions(+), 6 deletions(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:35:54
Switch posix_acls() to lookup fsids in the fsid mappings. If no fsid
mappings are setup the behavior is unchanged, i.e. fsids are looked up in the
id mappings.
Afaict, all filesystems that share a superblock in all user namespaces
currently do not support acls so this change should be safe to do
unconditionally.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
fs/posix_acl.c | 17 +++++++++--------
1 file changed, 9 insertions(+), 8 deletions(-)
Before we touch this code any more it needs to move to the right place.
Poking into ACLs from generic xattr code is a complete layering
violation, and all this needs to be moved so that it is called by
the actual handlers called from the file systems.
Before we touch this code any more it needs to move to the right place.
Poking into ACLs from generic xattr code is a complete layering
git history shows that it was deliberately placed after the fs specific
xattr handlers have been called so individual filesystems don't need to
be aware of id mappings to make maintenance easier. Same goes for vfs
capabilities. Moving this down into individual filesystem seems like a
maintenance nightmare where now each individual filesystem will have to
remember to fixup their ids. For namespaced vfs caps which are handled
at the same level in setxattr() it will also mean breaking backwards
compatible translation from non-namespaced vfs caps aware userspace to
namespaced vfs-caps aware kernels.
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:01
Switch cap_task_fix_setuid() to lookup fsids in the fsid mappings. If no fsid
mappings are setup the behavior is unchanged, i.e. fsids are looked up in the
id mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
security/commoncap.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:02
During exec the kfsids are currently reset to the effective kids. To retain the
same semantics with the introduction of fsid mappings, we lookup the userspace
effective id in the id mappings and translate the effective id into the
corresponding kfsid in the fsid mapping. This means, the behavior is unchanged
when no fsid mappings are setup and the semantics stay the same even when fsid
mappings are setup.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
- Christian Brauner [off-list ref]:
- Reset kfsids used for userns visible filesystems such as proc too.
/* v3 */
unchanged
---
security/commoncap.c | 17 ++++++++++++++---
1 file changed, 14 insertions(+), 3 deletions(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:05
Let chown_common() lookup fsids in the fsid mappings. If no fsid mappings are
setup the behavior is unchanged, i.e. fsids are looked up in the id mappings.
do_faccessat() just needs to translate from real ids into fsids.
Filesystems that share a superblock in all user namespaces they are mounted in
will retain their old semantics even with the introduction of fsid mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
- Christian Brauner [off-list ref]:
- handle faccessat() too
/* v3 */
unchanged
---
fs/open.c | 16 ++++++++++++----
1 file changed, 12 insertions(+), 4 deletions(-)
@@ -361,8 +362,10 @@ long do_faccessat(int dfd, const char __user *filename, int mode)if(!override_cred)return-ENOMEM;-override_cred->fsuid=override_cred->uid;-override_cred->fsgid=override_cred->gid;+override_cred->kfsuid=override_cred->uid;+override_cred->kfsgid=override_cred->gid;+override_cred->fsuid=kuid_to_kfsuid(override_cred->user_ns,override_cred->uid);+override_cred->fsgid=kgid_to_kfsgid(override_cred->user_ns,override_cred->gid);if(!issecure(SECURE_NO_SETUID_FIXUP)){/* Clear the capabilities if we switch to a non-root user */
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:14
Switch attribute functions looking up fsids to them up in the fsid mappings. If
no fsid mappings are setup the behavior is unchanged, i.e. fsids are looked up
in the id mappings.
Filesystems that share a superblock in all user namespaces they are mounted in
will retain their old semantics even with the introduction of fsid mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
- Tycho Andersen [off-list ref]:
- Replace , with = when converting to uid and gid in cp_new_stat64().
---
fs/stat.c | 48 +++++++++++++++++++++++++++++++++++---------
include/linux/stat.h | 1 +
2 files changed, 39 insertions(+), 10 deletions(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:15
Switch vfs cap helpers to lookup fsids in the fsid mappings. If no fsid
mappings are setup the behavior is unchanged, i.e. fsids are looked up in the
id mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
security/commoncap.c | 16 ++++++++--------
1 file changed, 8 insertions(+), 8 deletions(-)
@@ -411,11 +411,11 @@ int cap_inode_getsecurity(struct inode *inode, const char *name, void **buffer,nscap=(structvfs_ns_cap_data*)tmpbuf;root=le32_to_cpu(nscap->rootid);-kroot=make_kuid(fs_ns,root);+kroot=make_kfsuid(fs_ns,root);-/* If the root kuid maps to a valid uid in current ns, then return+/* If the root kfsuid maps to a valid uid in current ns, then return*thisasanscap.*/-mappedroot=from_kuid(current_user_ns(),kroot);+mappedroot=from_kfsuid(current_user_ns(),kroot);if(mappedroot!=(uid_t)-1&&mappedroot!=(uid_t)0){if(alloc){*buffer=tmpbuf;
On Tue, Feb 18, 2020 at 3:35 PM Christian Brauner
[off-list ref] wrote:
Switch vfs cap helpers to lookup fsids in the fsid mappings. If no fsid
mappings are setup the behavior is unchanged, i.e. fsids are looked up in the
id mappings.
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:21
Based on discussions with Jann we decided in order to cleanly handle nested
user namespaces that fsid mappings can only be written before the corresponding
id mappings have been written. Writing id mappings before writing the
corresponding fsid mappings causes fsid mappings to mirror id mappings.
Consider creating a user namespace NS1 with the initial user namespace as
parent. Assume NS1 receives id mapping 0 100000 100000 and fsid mappings 0
300000 100000. Files that root in NS1 will create will map to kfsuid=300000 and
kfsgid=300000 and will hence be owned by uid=300000 and gid 300000 on-disk in
the initial user namespace.
Now assume user namespace NS2 is created in user namespace NS1. Assume that NS2
receives id mapping 0 10000 65536 and an fsid mapping of 0 10000 65536. Files
that root in NS2 will create will map to kfsuid=10000 and kfsgid=10000 in NS1.
hence, files created by NS2 will hence be appear to be be owned by uid=10000
and gid=10000 on-disk in NS1. Looking at the initial user namespace, files
created by NS2 will map to kfsuid=310000 and kfsgid=310000 and hence will be
owned by uid=310000 and gid=310000 on-disk.
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
patch not present
/* v3 */
patch added
- Jann Horn [off-list ref]:
- Split changes to map_write() to implement fsid mappings into three separate
patches: basic fsid helpers, preparatory changes to map_write(), actual
fsid mapping support in map_write().
---
kernel/user_namespace.c | 165 ++++++++++++++++++++++++++++++++++------
1 file changed, 143 insertions(+), 22 deletions(-)
@@ -1064,9 +1108,17 @@ static int sort_map(struct uid_gid_map *map)return0;}-staticintsort_idmaps(structuid_gid_map*map)+staticintsort_idmaps(structuid_gid_map*map,+structuid_gid_map*new_fsid_map){-returnsort_map(map);+intret;++ret=sort_map(map);+if(ret)+returnret;++/* Sort fsid maps in case they mirror id maps. */+returnsort_map(new_fsid_map);}staticintmap_from_parent(structuid_gid_map*new_map,
@@ -1101,13 +1153,31 @@ static int map_from_parent(struct uid_gid_map *new_map,}staticintmap_into_kids(structuid_gid_map*id_map,-structuid_gid_map*parent_id_map)+structuid_gid_map*parent_id_map,+structuser_namespace*ns,+structuid_gid_map*new_fsid_map,enumidmap_typetype){-returnmap_from_parent(id_map,parent_id_map);+intret;++ret=map_from_parent(id_map,parent_id_map);+if(ret)+returnret;++#ifdef CONFIG_USER_NS_FSID+/* fsid maps mirror id maps. */+if(idmap_type_wants_fsidmap(type)&&idmap_exists(new_fsid_map))+ret=map_from_parent(new_fsid_map,+type==UID_MAP?&ns->parent->fsuid_map:+&ns->parent->fsgid_map);+#endif+returnret;}staticvoidinstall_idmaps(structuid_gid_map*id_map,-structuid_gid_map*new_id_map)+structuid_gid_map*new_id_map,+structuid_gid_map*fsid_map,+structuid_gid_map*new_fsid_map,+enumidmap_typetype){if(new_id_map->nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS){memcpy(id_map->extent,new_id_map->extent,
@@ -1173,6 +1266,7 @@ static ssize_t map_write(struct file *file, const char __user *buf,mutex_lock(&userns_state_mutex);memset(&new_map,0,sizeof(structuid_gid_map));+new_fsid_map.nr_extents=0;ret=-EPERM;/* Only allow one successful write to the map */
@@ -1252,10 +1346,21 @@ static ssize_t map_write(struct file *file, const char __user *buf,ret=-EPERM;/* Validate the user is allowed to use user id's mapped to. */-if(!new_idmap_permitted(file,ns,cap_setid,&new_map))+if(!new_idmap_permitted(file,ns,cap_setid,&new_map,type))+gotoout;++#ifdef CONFIG_USER_NS_FSID+/* Take pointer to fsid maps in case we're mirroring id maps. */+if(type==UID_MAP)+fsid_map=&ns->fsuid_map;+elseif(type==GID_MAP)+fsid_map=&ns->fsgid_map;+ret=idmap_to_fsidmap(&new_map,fsid_map,&new_fsid_map,type);+if(ret)gotoout;+#endif-ret=map_into_kids(&new_map,parent_map);+ret=map_into_kids(&new_map,parent_map,ns,&new_fsid_map,type);if(ret)gotoout;
@@ -1332,7 +1439,7 @@ ssize_t proc_projid_map_write(struct file *file, const char __user *buf,/* Anyone can set any valid project id no capability needed */returnmap_write(file,buf,size,ppos,-1,-&ns->projid_map,&ns->parent->projid_map);+&ns->projid_map,&ns->parent->projid_map,PROJID_MAP);}#ifdef CONFIG_USER_NS_FSID
@@ -1367,15 +1474,25 @@ ssize_t proc_fsgid_map_write(struct file *file, const char __user *buf,return-EPERM;returnmap_write(file,buf,size,ppos,CAP_SETGID,&ns->fsgid_map,-&ns->parent->fsgid_map);+&ns->parent->fsgid_map,FSGID_MAP);}#endifstaticboolnew_idmap_permitted(conststructfile*file,structuser_namespace*ns,intcap_setid,-structuid_gid_map*new_map)+structuid_gid_map*new_map,+enumidmap_typeidmap_type){conststructcred*cred=file->f_cred;++/* Don't allow writing fsuid maps when uid maps have been written. */+if(idmap_type==FSUID_MAP&&idmap_exists(&ns->uid_map))+returnfalse;++/* Don't allow writing fsgid maps when gid maps have been written. */+if(idmap_type==FSGID_MAP&&idmap_exists(&ns->gid_map))+returnfalse;+/* Don't allow mappings that would allow anything that wouldn't*beallowedwithouttheestablishmentofunprivilegedmappings.*/
On Tue, Feb 18, 2020 at 3:35 PM Christian Brauner
[off-list ref] wrote:
Based on discussions with Jann we decided in order to cleanly handle nested
user namespaces that fsid mappings can only be written before the corresponding
id mappings have been written. Writing id mappings before writing the
corresponding fsid mappings causes fsid mappings to mirror id mappings.
Consider creating a user namespace NS1 with the initial user namespace as
parent. Assume NS1 receives id mapping 0 100000 100000 and fsid mappings 0
300000 100000. Files that root in NS1 will create will map to kfsuid=300000 and
kfsgid=300000 and will hence be owned by uid=300000 and gid 300000 on-disk in
the initial user namespace.
Now assume user namespace NS2 is created in user namespace NS1. Assume that NS2
receives id mapping 0 10000 65536 and an fsid mapping of 0 10000 65536. Files
that root in NS2 will create will map to kfsuid=10000 and kfsgid=10000 in NS1.
hence, files created by NS2 will hence be appear to be be owned by uid=10000
and gid=10000 on-disk in NS1. Looking at the initial user namespace, files
created by NS2 will map to kfsuid=310000 and kfsgid=310000 and hence will be
owned by uid=310000 and gid=310000 on-disk.
[...]
static bool new_idmap_permitted(const struct file *file,
struct user_namespace *ns, int cap_setid,
- struct uid_gid_map *new_map)
+ struct uid_gid_map *new_map,
+ enum idmap_type idmap_type)
{
const struct cred *cred = file->f_cred;
+
+ /* Don't allow writing fsuid maps when uid maps have been written. */
+ if (idmap_type == FSUID_MAP && idmap_exists(&ns->uid_map))
+ return false;
+
+ /* Don't allow writing fsgid maps when gid maps have been written. */
+ if (idmap_type == FSGID_MAP && idmap_exists(&ns->gid_map))
+ return false;
Why are these checks necessary? Shouldn't an fs*id map have already
been implicitly created?
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:24
This adds a set of helpers to translate between kfsuid/kfsgid and their
userspace fsuid/fsgid counter parts relative to a given user namespace.
- kuid_t make_kfsuid(struct user_namespace *from, uid_t fsuid)
Maps a user-namespace fsuid pair into a kfsuid.
If no fsuid mappings have been written it behaves identical to calling
make_kuid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- kgid_t make_kfsgid(struct user_namespace *from, gid_t fsgid)
Maps a user-namespace fsgid pair into a kfsgid.
If no fsgid mappings have been written it behaves identical to calling
make_kgid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- uid_t from_kfsuid(struct user_namespace *to, kuid_t fsuid)
Creates a fsuid from a kfsuid user-namespace pair if possible.
If no fsuid mappings have been written it behaves identical to calling
from_kuid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- gid_t from_kfsgid(struct user_namespace *to, kgid_t fsgid)
Creates a fsgid from a kfsgid user-namespace pair if possible.
If no fsgid mappings have been written it behaves identical to calling
make_kgid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- uid_t from_kfsuid_munged(struct user_namespace *to, kuid_t fsuid)
Always creates a fsuid from a kfsuid user-namespace pair.
If no fsuid mappings have been written it behaves identical to calling
from_kuid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- gid_t from_kfsgid_munged(struct user_namespace *to, kgid_t fsgid)
Always creates a fsgid from a kfsgid user-namespace pair if possible.
If no fsgid mappings have been written it behaves identical to calling
make_kgid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- bool kfsuid_has_mapping(struct user_namespace *ns, kuid_t uid)
Check whether this kfsuid has a mapping in the provided user namespace.
If no fsuid mappings have been written it behaves identical to calling
from_kuid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- bool kfsgid_has_mapping(struct user_namespace *ns, kgid_t gid)
Check whether this kfsgid has a mapping in the provided user namespace.
If no fsgid mappings have been written it behaves identical to calling
make_kgid(). This ensures backwards compatibility for workloads unaware
or not in need of fsid mappings.
- kuid_t kfsuid_to_kuid(struct user_namespace *to, kuid_t kfsuid)
Translate from a kfsuid into a kuid.
- kgid_t kfsgid_to_kgid(struct user_namespace *to, kgid_t kfsgid)
Translate from a kfsgid into a kgid.
- kuid_t kuid_to_kfsuid(struct user_namespace *to, kuid_t kuid)
Translate from a kuid into a kfsuid.
- kgid_t kgid_to_kfsuid(struct user_namespace *to, kgid_t kgid)
Translate from a kgid into a kfsgid.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
- Jann Horn [off-list ref]:
- Split changes to map_write() to implement fsid mappings into three separate
patches: basic fsid helpers, preparatory changes to map_write(), actual
fsid mapping support in map_write().
---
include/linux/fsuidgid.h | 122 +++++++++++++++++++++++++++++++++
kernel/user_namespace.c | 141 ++++++++++++++++++++++++++++++++++++++-
2 files changed, 261 insertions(+), 2 deletions(-)
create mode 100644 include/linux/fsuidgid.h
@@ -583,6 +584,142 @@ projid_t from_kprojid_munged(struct user_namespace *targ, kprojid_t kprojid)}EXPORT_SYMBOL(from_kprojid_munged);+#ifdef CONFIG_USER_NS_FSID+/**+*make_kfsuid-Mapauser-namespacefsuidpairintoakuid.+*@ns:Usernamespacethatthefsuidisin+*@fsuid:Useridentifier+*+*Mapsauser-namespacefsuidpairintoakernelinternalkfsuid,+*andreturnsthatkfsuid.+*+*Whenthereisnomappingdefinedfortheuser-namespacekfsuid+*pairINVALID_UIDisreturned.Callersareexpectedtotest+*forandhandleINVALID_UIDbeingreturned.INVALID_UID+*maybetestedforusinguid_valid().+*/+kuid_tmake_kfsuid(structuser_namespace*ns,uid_tfsuid)+{+/* Map the fsuid to a global kernel fsuid */+returnKUIDT_INIT(map_id_down(&ns->fsuid_map,fsuid));+}+EXPORT_SYMBOL(make_kfsuid);++/**+*from_kfsuid-Createafsuidfromakfsuiduser-namespacepair.+*@targ:Theusernamespacewewantafsuidin.+*@kfsuid:Thekernelinternalfsuidtostartwith.+*+*Map@kfsuidintotheuser-namespacespecifiedby@targand+*returntheresultingfsuid.+*+*Thereisalwaysamappingintotheinitialuser_namespace.+*+*If@kfsuidhasnomappingin@targ(uid_t)-1isreturned.+*/+uid_tfrom_kfsuid(structuser_namespace*targ,kuid_tkfsuid)+{+/* Map the fsuid from a global kernel fsuid */+returnmap_id_up(&targ->fsuid_map,__kuid_val(kfsuid));+}+EXPORT_SYMBOL(from_kfsuid);++/**+*from_kfsuid_munged-Createafsuidfromakfsuiduser-namespacepair.+*@targ:Theusernamespacewewantafsuidin.+*@kfsuid:Thekernelinternalfsuidtostartwith.+*+*Map@kfsuidintotheuser-namespacespecifiedby@targand+*returntheresultingfsuid.+*+*Thereisalwaysamappingintotheinitialuser_namespace.+*+*Unlikefrom_kfsuidfrom_kfsuid_mungedneverfailsandalways+*returnsavalidfsuid.Thismakesfrom_kfsuid_mungedappropriate+*foruseinsyscallslikestatandgetuidwherefailingthe+*systemcallandfailingtoprovideavalidfsuidarenotan+*options.+*+*If@kfsuidhasnomappingin@targoverflowuidisreturned.+*/+uid_tfrom_kfsuid_munged(structuser_namespace*targ,kuid_tkfsuid)+{+uid_tfsuid;+fsuid=from_kfsuid(targ,kfsuid);++if(fsuid==(uid_t)-1)+fsuid=overflowuid;+returnfsuid;+}+EXPORT_SYMBOL(from_kfsuid_munged);++/**+*make_kfsgid-Mapauser-namespacefsgidpairintoakfsgid.+*@ns:Usernamespacethatthefsgidisin+*@fsgid:Useridentifier+*+*Mapsauser-namespacefsgidpairintoakernelinternalkfsgid,+*andreturnsthatkfsgid.+*+*Whenthereisnomappingdefinedfortheuser-namespacefsgid+*pairINVALID_GIDisreturned.Callersareexpectedtotest+*forandhandleINVALID_GIDbeingreturned.INVALID_GID+*maybetestedforusinggid_valid().+*/+kgid_tmake_kfsgid(structuser_namespace*ns,gid_tfsgid)+{+/* Map the fsgid to a global kernel fsgid */+returnKGIDT_INIT(map_id_down(&ns->fsgid_map,fsgid));+}+EXPORT_SYMBOL(make_kfsgid);++/**+*from_kfsgid-Createafsgidfromakfsgiduser-namespacepair.+*@targ:Theusernamespacewewantafsgidin.+*@kfsgid:Thekernelinternalfsgidtostartwith.+*+*Map@kfsgidintotheuser-namespacespecifiedby@targand+*returntheresultingfsgid.+*+*Thereisalwaysamappingintotheinitialuser_namespace.+*+*If@kfsgidhasnomappingin@targ(gid_t)-1isreturned.+*/+gid_tfrom_kfsgid(structuser_namespace*targ,kgid_tkfsgid)+{+/* Map the fsgid from a global kernel fsgid */+returnmap_id_up(&targ->fsgid_map,__kgid_val(kfsgid));+}+EXPORT_SYMBOL(from_kfsgid);++/**+*from_kfsgid_munged-Createafsgidfromakfsgiduser-namespacepair.+*@targ:Theusernamespacewewantafsgidin.+*@kfsgid:Thekernelinternalfsgidtostartwith.+*+*Map@kfsgidintotheuser-namespacespecifiedby@targand+*returntheresultingfsgid.+*+*Thereisalwaysamappingintotheinitialuser_namespace.+*+*Unlikefrom_kfsgidfrom_kfsgid_mungedneverfailsandalways+*returnsavalidfsgid.Thismakesfrom_kfsgid_mungedappropriate+*foruseinsyscallslikestatandgetgidwherefailingthe+*systemcallandfailingtoprovideavalidfsgidarenotoptions.+*+*If@kfsgidhasnomappingin@targoverflowgidisreturned.+*/+gid_tfrom_kfsgid_munged(structuser_namespace*targ,kgid_tkfsgid)+{+gid_tfsgid;+fsgid=from_kfsgid(targ,kfsgid);++if(fsgid==(gid_t)-1)+fsgid=overflowgid;+returnfsgid;+}+EXPORT_SYMBOL(from_kfsgid_munged);+#endif /* CONFIG_USER_NS_FSID */staticintuid_m_show(structseq_file*seq,void*v){
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:24
After the introduction of fsid mappings we need to carefully handle
single-superblock filesystems that are visible in user namespaces. This
specifically concerns proc and sysfs. For those filesystems we want to continue
looking up fsid in the id mappings of the relevant user namespace. We can
either do this by dynamically translating between these fsids or we simply keep
them around with the other creds. The latter option is not just simpler but
also more performant since we don't need to do the translation from fsid
mappings into id mappings on the fly.
Link: https://lore.kernel.org/r/20200212145149.zohmc6d3x52bw6j6@wittgenstein
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
patch added
/* v3 */
unchanged
---
include/linux/cred.h | 4 ++++
1 file changed, 4 insertions(+)
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:34
Refactor map_write() to prepare for adding fsid mappings support. This mainly
factors out various open-coded parts into helpers that can be reused in the
follow up patch.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
patch not present
/* v3 */
patch added
- Jann Horn [off-list ref]:
- Split changes to map_write() to implement fsid mappings into three separate
patches: basic fsid helpers, preparatory changes to map_write(), actual
fsid mapping support in map_write().
---
kernel/user_namespace.c | 117 +++++++++++++++++++++++++---------------
1 file changed, 74 insertions(+), 43 deletions(-)
@@ -1064,6 +1064,71 @@ static int sort_idmaps(struct uid_gid_map *map)return0;}+staticintsort_idmaps(structuid_gid_map*map)+{+returnsort_map(map);+}++staticintmap_from_parent(structuid_gid_map*new_map,+structuid_gid_map*parent_map)+{+unsignedidx;++/* Map the lower ids from the parent user namespace to the+*kernelglobalidspace.+*/+for(idx=0;idx<new_map->nr_extents;idx++){+structuid_gid_extent*e;+u32lower_first;++if(new_map->nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS)+e=&new_map->extent[idx];+else+e=&new_map->forward[idx];++lower_first=map_id_range_down(parent_map,e->lower_first,e->count);++/* Fail if we can not map the specified extent to+*thekernelglobalidspace.+*/+if(lower_first==(u32)-1)+return-EPERM;++e->lower_first=lower_first;+}++return0;+}++staticintmap_into_kids(structuid_gid_map*id_map,+structuid_gid_map*parent_id_map)+{+returnmap_from_parent(id_map,parent_id_map);+}++staticvoidinstall_idmaps(structuid_gid_map*id_map,+structuid_gid_map*new_id_map)+{+if(new_id_map->nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS){+memcpy(id_map->extent,new_id_map->extent,+new_id_map->nr_extents*sizeof(new_id_map->extent[0]));+}else{+id_map->forward=new_id_map->forward;+id_map->reverse=new_id_map->reverse;+}+}++staticvoidfree_idmaps(structuid_gid_map*new_id_map)+{+if(new_id_map->nr_extents>UID_GID_MAP_MAX_BASE_EXTENTS){+kfree(new_id_map->forward);+kfree(new_id_map->reverse);+new_id_map->forward=NULL;+new_id_map->reverse=NULL;+new_id_map->nr_extents=0;+}+}+staticssize_tmap_write(structfile*file,constchar__user*buf,size_tcount,loff_t*ppos,intcap_setid,
@@ -1191,61 +1255,28 @@ static ssize_t map_write(struct file *file, const char __user *buf,if(!new_idmap_permitted(file,ns,cap_setid,&new_map))gotoout;-ret=-EPERM;-/* Map the lower ids from the parent user namespace to the-*kernelglobalidspace.-*/-for(idx=0;idx<new_map.nr_extents;idx++){-structuid_gid_extent*e;-u32lower_first;--if(new_map.nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS)-e=&new_map.extent[idx];-else-e=&new_map.forward[idx];--lower_first=map_id_range_down(parent_map,-e->lower_first,-e->count);--/* Fail if we can not map the specified extent to-*thekernelglobalidspace.-*/-if(lower_first==(u32)-1)-gotoout;--e->lower_first=lower_first;-}+ret=map_into_kids(&new_map,parent_map);+if(ret)+gotoout;/**Ifwewanttousebinarysearchforlookup,thisclonestheextent*arrayandsortsbothcopies.*/ret=sort_idmaps(&new_map);-if(ret<0)+if(ret)gotoout;/* Install the map */-if(new_map.nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS){-memcpy(map->extent,new_map.extent,-new_map.nr_extents*sizeof(new_map.extent[0]));-}else{-map->forward=new_map.forward;-map->reverse=new_map.reverse;-}+install_idmaps(map,&new_map);smp_wmb();map->nr_extents=new_map.nr_extents;*ppos=count;ret=count;out:-if(ret<0&&new_map.nr_extents>UID_GID_MAP_MAX_BASE_EXTENTS){-kfree(new_map.forward);-kfree(new_map.reverse);-map->forward=NULL;-map->reverse=NULL;-map->nr_extents=0;-}+if(ret<0)+free_idmaps(&new_map);mutex_unlock(&userns_state_mutex);kfree(kbuf);
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 02:35:59
On Tue, Feb 18, 2020 at 03:33:51PM +0100, Christian Brauner wrote:
Refactor map_write() to prepare for adding fsid mappings support. This mainly
factors out various open-coded parts into helpers that can be reused in the
follow up patch.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
Acked-by: Serge Hallyn <serge@hallyn.com>
quoted hunk
---
/* v2 */
patch not present
/* v3 */
patch added
- Jann Horn [off-list ref]:
- Split changes to map_write() to implement fsid mappings into three separate
patches: basic fsid helpers, preparatory changes to map_write(), actual
fsid mapping support in map_write().
---
kernel/user_namespace.c | 117 +++++++++++++++++++++++++---------------
1 file changed, 74 insertions(+), 43 deletions(-)
@@ -1064,6 +1064,71 @@ static int sort_idmaps(struct uid_gid_map *map)return0;}+staticintsort_idmaps(structuid_gid_map*map)+{+returnsort_map(map);+}++staticintmap_from_parent(structuid_gid_map*new_map,+structuid_gid_map*parent_map)+{+unsignedidx;++/* Map the lower ids from the parent user namespace to the+*kernelglobalidspace.+*/+for(idx=0;idx<new_map->nr_extents;idx++){+structuid_gid_extent*e;+u32lower_first;++if(new_map->nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS)+e=&new_map->extent[idx];+else+e=&new_map->forward[idx];++lower_first=map_id_range_down(parent_map,e->lower_first,e->count);++/* Fail if we can not map the specified extent to+*thekernelglobalidspace.+*/+if(lower_first==(u32)-1)+return-EPERM;++e->lower_first=lower_first;+}++return0;+}++staticintmap_into_kids(structuid_gid_map*id_map,+structuid_gid_map*parent_id_map)+{+returnmap_from_parent(id_map,parent_id_map);+}++staticvoidinstall_idmaps(structuid_gid_map*id_map,+structuid_gid_map*new_id_map)+{+if(new_id_map->nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS){+memcpy(id_map->extent,new_id_map->extent,+new_id_map->nr_extents*sizeof(new_id_map->extent[0]));+}else{+id_map->forward=new_id_map->forward;+id_map->reverse=new_id_map->reverse;+}+}++staticvoidfree_idmaps(structuid_gid_map*new_id_map)+{+if(new_id_map->nr_extents>UID_GID_MAP_MAX_BASE_EXTENTS){+kfree(new_id_map->forward);+kfree(new_id_map->reverse);+new_id_map->forward=NULL;+new_id_map->reverse=NULL;+new_id_map->nr_extents=0;+}+}+staticssize_tmap_write(structfile*file,constchar__user*buf,size_tcount,loff_t*ppos,intcap_setid,
@@ -1191,61 +1255,28 @@ static ssize_t map_write(struct file *file, const char __user *buf,if(!new_idmap_permitted(file,ns,cap_setid,&new_map))gotoout;-ret=-EPERM;-/* Map the lower ids from the parent user namespace to the-*kernelglobalidspace.-*/-for(idx=0;idx<new_map.nr_extents;idx++){-structuid_gid_extent*e;-u32lower_first;--if(new_map.nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS)-e=&new_map.extent[idx];-else-e=&new_map.forward[idx];--lower_first=map_id_range_down(parent_map,-e->lower_first,-e->count);--/* Fail if we can not map the specified extent to-*thekernelglobalidspace.-*/-if(lower_first==(u32)-1)-gotoout;--e->lower_first=lower_first;-}+ret=map_into_kids(&new_map,parent_map);+if(ret)+gotoout;/**Ifwewanttousebinarysearchforlookup,thisclonestheextent*arrayandsortsbothcopies.*/ret=sort_idmaps(&new_map);-if(ret<0)+if(ret)gotoout;/* Install the map */-if(new_map.nr_extents<=UID_GID_MAP_MAX_BASE_EXTENTS){-memcpy(map->extent,new_map.extent,-new_map.nr_extents*sizeof(new_map.extent[0]));-}else{-map->forward=new_map.forward;-map->reverse=new_map.reverse;-}+install_idmaps(map,&new_map);smp_wmb();map->nr_extents=new_map.nr_extents;*ppos=count;ret=count;out:-if(ret<0&&new_map.nr_extents>UID_GID_MAP_MAX_BASE_EXTENTS){-kfree(new_map.forward);-kfree(new_map.reverse);-map->forward=NULL;-map->reverse=NULL;-map->nr_extents=0;-}+if(ret<0)+free_idmaps(&new_map);mutex_unlock(&userns_state_mutex);kfree(kbuf);
@@ -33,7 +33,7 @@ int key_task_permission(const key_ref_t key_ref, const struct cred *cred,key=key_ref_to_ptr(key_ref);/* use the second 8-bits of permissions for keys the caller owns */-if(uid_eq(key->uid,cred->fsuid)){+if(uid_eq(key->uid,cred->kfsuid)){kperm=key->perm>>16;gotouse_these_perms;}
@@ -41,7 +41,7 @@ int key_task_permission(const key_ref_t key_ref, const struct cred *cred,/* use the third 8-bits of permissions for keys the caller has a group*membershipincommonwith*/if(gid_valid(key->gid)&&key->perm&KEY_GRP_ALL){-if(gid_eq(key->gid,cred->fsgid)){+if(gid_eq(key->gid,cred->kfsgid)){kperm=key->perm>>8;gotouse_these_perms;}
@@ -149,8 +149,8 @@ static int call_sbin_request_key(struct key *authkey, void *aux)gotoerror_link;/* record the UID and GID */-sprintf(uid_str,"%d",from_kuid(&init_user_ns,cred->fsuid));-sprintf(gid_str,"%d",from_kgid(&init_user_ns,cred->fsgid));+sprintf(uid_str,"%d",from_kuid(&init_user_ns,cred->kfsuid));+sprintf(gid_str,"%d",from_kgid(&init_user_ns,cred->kfsgid));/* we say which key is under construction */sprintf(key_str,"%d",key->serial);
@@ -390,7 +390,7 @@ static int construct_alloc_key(struct keyring_search_context *ctx,perm|=KEY_POS_WRITE;key=key_alloc(ctx->index_key.type,ctx->index_key.description,-ctx->cred->fsuid,ctx->cred->fsgid,ctx->cred,+ctx->cred->kfsuid,ctx->cred->kfsgid,ctx->cred,perm,flags,NULL);if(IS_ERR(key))gotoalloc_failed;
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:43
This introduces the infrastructure to setup fsid mappings which will be used in
later patches.
All new code depends on CONFIG_USER_NS_FSID=y. It currently defaults to "N".
If CONFIG_USER_NS_FSID is not set, no new code is added.
In this patch fsuid_m_show() and fsgid_m_show() are introduced. They are
identical to uid_m_show() and gid_m_show() until we introduce from_kfsuid() and
from_kfsgid() in a follow-up patch.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
- Randy Dunlap [off-list ref]:
- Fix typo in USER_NS_FSID kconfig documentation.
/* v3 */
unchanged
---
include/linux/user_namespace.h | 10 +++
init/Kconfig | 11 +++
kernel/user.c | 22 ++++++
kernel/user_namespace.c | 122 +++++++++++++++++++++++++++++++++
4 files changed, 165 insertions(+)
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 02:33:34
On Tue, Feb 18, 2020 at 03:33:47PM +0100, Christian Brauner wrote:
This introduces the infrastructure to setup fsid mappings which will be used in
later patches.
All new code depends on CONFIG_USER_NS_FSID=y. It currently defaults to "N".
If CONFIG_USER_NS_FSID is not set, no new code is added.
In this patch fsuid_m_show() and fsgid_m_show() are introduced. They are
identical to uid_m_show() and gid_m_show() until we introduce from_kfsuid() and
from_kfsgid() in a follow-up patch.
Signed-off-by: Christian Brauner <redacted>
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:48
If fsid mappings have been written, this will cause proc to look at fsid
mappings for the user namespace. If no fsid mappings have been written the
behavior is as before.
Here is part of the output from /proc/<pid>/status from the initial user
namespace for systemd running in an unprivileged container as user namespace
root with id mapping 0 100000 100000 and fsid mapping 0 300000 100000:
Name: systemd
Umask: 0000
State: S (sleeping)
Tgid: 13023
Ngid: 0
Pid: 13023
PPid: 13008
TracerPid: 0
Uid: 100000 100000 100000 300000
Gid: 100000 100000 100000 300000
FDSize: 64
Groups:
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
fs/proc/array.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 02:36:25
On Tue, Feb 18, 2020 at 03:33:53PM +0100, Christian Brauner wrote:
If fsid mappings have been written, this will cause proc to look at fsid
mappings for the user namespace. If no fsid mappings have been written the
behavior is as before.
Here is part of the output from /proc/<pid>/status from the initial user
namespace for systemd running in an unprivileged container as user namespace
root with id mapping 0 100000 100000 and fsid mapping 0 300000 100000:
Name: systemd
Umask: 0000
State: S (sleeping)
Tgid: 13023
Ngid: 0
Pid: 13023
PPid: 13008
TracerPid: 0
Uid: 100000 100000 100000 300000
Gid: 100000 100000 100000 300000
FDSize: 64
Groups:
Signed-off-by: Christian Brauner <redacted>
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:51
The /proc/<pid>/fsuid_map file can be written once to setup an fsuid mapping
for a user namespace. Writing to this file has the same restrictions as writing
to /proc/<pid>/fsuid_map:
root@e1-vm:/# cat /proc/13023/fsuid_map
0 300000 100000
Fsid mappings have always been around. They are currently always identical to
the id mappings for a user namespace. This means, currently whenever an fsid
needs to be looked up the kernel will use the id mapping of the user namespace.
With the introduction of fsid mappings the kernel will now lookup fsids in the
fsid mappings of the user namespace. If no fsid mapping exists the kernel will
continue looking up fsids in the id mappings of the user namespace. Hence, if a
system supports fsid mappings through /proc/<pid>/fs*id_map and a container
runtime is not aware of fsid mappings it or does not use them it will it will
continue to work just as before.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
- Christian Brauner [off-list ref]:
- Fix grammar in commit message.
---
fs/proc/base.c | 20 ++++++++++++++++++++
1 file changed, 20 insertions(+)
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 02:33:41
On Tue, Feb 18, 2020 at 03:33:48PM +0100, Christian Brauner wrote:
The /proc/<pid>/fsuid_map file can be written once to setup an fsuid mapping
for a user namespace. Writing to this file has the same restrictions as writing
to /proc/<pid>/fsuid_map:
root@e1-vm:/# cat /proc/13023/fsuid_map
0 300000 100000
Fsid mappings have always been around. They are currently always identical to
the id mappings for a user namespace. This means, currently whenever an fsid
needs to be looked up the kernel will use the id mapping of the user namespace.
With the introduction of fsid mappings the kernel will now lookup fsids in the
fsid mappings of the user namespace. If no fsid mapping exists the kernel will
continue looking up fsids in the id mappings of the user namespace. Hence, if a
system supports fsid mappings through /proc/<pid>/fs*id_map and a container
runtime is not aware of fsid mappings it or does not use them it will it will
continue to work just as before.
Signed-off-by: Christian Brauner <redacted>
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:52
Switch inode_owner_or_capable() to lookup fsids in the fsid mappings. If no
fsid mappings are setup the behavior is unchanged, i.e. fsids are looked up in
the id mappings.
Filesystems that share a superblock in all user namespaces they are mounted in
will retain their old semantics even with the introduction of fsid mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
fs/inode.c | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:36:59
The /proc/<pid>/fsgid_map file can be written once to setup an fsgid mapping
for a user namespace. Writing to this file has the same restrictions as writing
to /proc/<pid>/fsgid_map.
root@e1-vm:/# cat /proc/13023/fsgid_map
0 300000 100000
Fsid mappings have always been around. They are currently always identical to
the id mappings for a user namespace. This means, currently whenever an fsid
needs to be looked up the kernel will use the id mapping of the user namespace.
With the introduction of fsid mappings the kernel will now lookup fsids in the
fsid mappings of the user namespace. If no fsid mapping exists the kernel will
continue looking up fsids in the id mappings of the user namespace. Hence, if a
system supports fsid mappings through /proc/<pid>/fs*id_map and a container
runtime is not aware of fsid mappings it or does not use them it will it will
continue to work just as before.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
- Christian Brauner [off-list ref]:
- Fix grammar in commit message.
---
fs/proc/base.c | 14 ++++++++++++++
1 file changed, 14 insertions(+)
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 02:33:50
On Tue, Feb 18, 2020 at 03:33:49PM +0100, Christian Brauner wrote:
The /proc/<pid>/fsgid_map file can be written once to setup an fsgid mapping
for a user namespace. Writing to this file has the same restrictions as writing
to /proc/<pid>/fsgid_map.
root@e1-vm:/# cat /proc/13023/fsgid_map
0 300000 100000
Fsid mappings have always been around. They are currently always identical to
the id mappings for a user namespace. This means, currently whenever an fsid
needs to be looked up the kernel will use the id mapping of the user namespace.
With the introduction of fsid mappings the kernel will now lookup fsids in the
fsid mappings of the user namespace. If no fsid mapping exists the kernel will
continue looking up fsids in the id mappings of the user namespace. Hence, if a
system supports fsid mappings through /proc/<pid>/fs*id_map and a container
runtime is not aware of fsid mappings it or does not use them it will it will
continue to work just as before.
Signed-off-by: Christian Brauner <redacted>
From: Christian Brauner <hidden> Date: 2020-02-18 14:37:03
When a uid or gid mount option is specified with devpts have it lookup the
corresponding kfsids in the fsid mappings. If no fsid mappings are setup the
behavior is unchanged, i.e. fsids are looked up in the id mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
fs/devpts/inode.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:37:08
Introduce a helper which makes it possible to detect fileystems whose
superblock is visible in multiple user namespace. This currently only
means proc and sys. Such filesystems usually have special semantics so their
behavior will not be changed with the introduction of fsid mappings.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
unchanged
/* v3 */
unchanged
---
include/linux/fs.h | 5 +++++
1 file changed, 5 insertions(+)
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 02:42:39
On Tue, Feb 18, 2020 at 03:33:55PM +0100, Christian Brauner wrote:
Introduce a helper which makes it possible to detect fileystems whose
superblock is visible in multiple user namespace. This currently only
means proc and sys. Such filesystems usually have special semantics so their
behavior will not be changed with the introduction of fsid mappings.
Hi,
I'm afraid I've got a bit of a hangup about the terminology here. I
*think* what you mean is that SB_I_USERNS_VISIBLE is an fs whose uids are
always translated per the id mappings, not fsid mappings. But when I see
the name it seems to imply that !SB_I_USERNS_VISIBLE filesystems can't
be seen by other namespaces at all.
Am I right in my first interpretation? If so, can we talk about the
naming?
From: Christian Brauner <hidden> Date: 2020-02-19 12:06:28
On Tue, Feb 18, 2020 at 08:42:33PM -0600, Serge Hallyn wrote:
On Tue, Feb 18, 2020 at 03:33:55PM +0100, Christian Brauner wrote:
quoted
Introduce a helper which makes it possible to detect fileystems whose
superblock is visible in multiple user namespace. This currently only
means proc and sys. Such filesystems usually have special semantics so their
behavior will not be changed with the introduction of fsid mappings.
Hi,
I'm afraid I've got a bit of a hangup about the terminology here. I
*think* what you mean is that SB_I_USERNS_VISIBLE is an fs whose uids are
always translated per the id mappings, not fsid mappings. But when I see
Correct!
the name it seems to imply that !SB_I_USERNS_VISIBLE filesystems can't
be seen by other namespaces at all.
Am I right in my first interpretation? If so, can we talk about the
naming?
Yep, your first interpretation is right. What about: wants_idmaps()
From: Andy Lutomirski <luto@kernel.org> Date: 2020-02-19 17:19:08
On Wed, Feb 19, 2020 at 4:06 AM Christian Brauner
[off-list ref] wrote:
On Tue, Feb 18, 2020 at 08:42:33PM -0600, Serge Hallyn wrote:
quoted
On Tue, Feb 18, 2020 at 03:33:55PM +0100, Christian Brauner wrote:
quoted
Introduce a helper which makes it possible to detect fileystems whose
superblock is visible in multiple user namespace. This currently only
means proc and sys. Such filesystems usually have special semantics so their
behavior will not be changed with the introduction of fsid mappings.
Hi,
I'm afraid I've got a bit of a hangup about the terminology here. I
*think* what you mean is that SB_I_USERNS_VISIBLE is an fs whose uids are
always translated per the id mappings, not fsid mappings. But when I see
Correct!
quoted
the name it seems to imply that !SB_I_USERNS_VISIBLE filesystems can't
be seen by other namespaces at all.
Am I right in my first interpretation? If so, can we talk about the
naming?
Yep, your first interpretation is right. What about: wants_idmaps()
Maybe fsidmap_exempt()?
I still haven't convinced myself that any of the above is actually
correct behavior, especially when people do things like creating
setuid binaries.
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-20 14:26:30
On Wed, Feb 19, 2020 at 09:18:51AM -0800, Andy Lutomirski wrote:
On Wed, Feb 19, 2020 at 4:06 AM Christian Brauner
[off-list ref] wrote:
quoted
On Tue, Feb 18, 2020 at 08:42:33PM -0600, Serge Hallyn wrote:
quoted
On Tue, Feb 18, 2020 at 03:33:55PM +0100, Christian Brauner wrote:
quoted
Introduce a helper which makes it possible to detect fileystems whose
superblock is visible in multiple user namespace. This currently only
means proc and sys. Such filesystems usually have special semantics so their
behavior will not be changed with the introduction of fsid mappings.
Hi,
I'm afraid I've got a bit of a hangup about the terminology here. I
*think* what you mean is that SB_I_USERNS_VISIBLE is an fs whose uids are
always translated per the id mappings, not fsid mappings. But when I see
Correct!
quoted
the name it seems to imply that !SB_I_USERNS_VISIBLE filesystems can't
be seen by other namespaces at all.
Am I right in my first interpretation? If so, can we talk about the
naming?
Yep, your first interpretation is right. What about: wants_idmaps()
Maybe fsidmap_exempt()?
Yeah, and maybe SB_USERNS_FSID_EXEMPT ?
I still haven't convinced myself that any of the above is actually
correct behavior, especially when people do things like creating
setuid binaries.
The only place that would be a problem is if the child userns has an
fsidmapping from X to 0 in the parent userns, right? Yeah I'm sure
many people would ignore all advice to the contrary and do this anyway,
but I would try hard to suggest that people use an intermediary userns
for storing filesystems for the "docker share" case. So the host fsid
range would start at say 200000. So a setuid binary would just be
setuid-200000.
From: Christian Brauner <hidden> Date: 2020-02-18 14:37:14
Switch may_{o_}create() to lookup fsids in the fsid mappings. If no fsid
mappings are setup the behavior is unchanged, i.e. fsids are looked up in the
id mappings.
Filesystems that share a superblock in all user namespaces they are mounted in
will retain their old semantics even with the introduction of fsid mappings.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
- Jann Horn [off-list ref]:
- Ensure that the correct fsid is used when dealing with userns visible
filesystems like proc.
/* v3 */
unchanged
---
fs/namei.c | 36 ++++++++++++++++++++++++++++--------
1 file changed, 28 insertions(+), 8 deletions(-)
@@ -287,6 +288,13 @@ static int check_acl(struct inode *inode, int mask)return-EAGAIN;}+staticinlinekuid_tget_current_fsuid(conststructinode*inode)+{+if(is_userns_visible(inode->i_sb->s_iflags))+returncurrent_kfsuid();+returncurrent_fsuid();+}+/**Thisdoesthebasicpermissionchecking*/
@@ -294,7 +302,7 @@ static int acl_permission_check(struct inode *inode, int mask){unsignedintmode=inode->i_mode;-if(likely(uid_eq(current_fsuid(),inode->i_uid)))+if(likely(uid_eq(get_current_fsuid(inode),inode->i_uid)))mode>>=6;else{if(IS_POSIXACL(inode)&&(mode&S_IRWXG)){
@@ -980,7 +988,7 @@ static inline int may_follow_link(struct nameidata *nd)/* Allowed if owner and follower match. */inode=nd->link_inode;-if(uid_eq(current_cred()->fsuid,inode->i_uid))+if(uid_eq(get_current_fsuid(inode),inode->i_uid))return0;/* Allowed if parent directory not sticky and world-writable. */
@@ -1097,7 +1105,7 @@ static int may_create_in_sticky(umode_t dir_mode, kuid_t dir_uid,(!sysctl_protected_regular&&S_ISREG(inode->i_mode))||likely(!(dir_mode&S_ISVTX))||uid_eq(inode->i_uid,dir_uid)||-uid_eq(current_fsuid(),inode->i_uid))+uid_eq(get_current_fsuid(inode),inode->i_uid))return0;if(likely(dir_mode&0002)||
@@ -2902,6 +2910,20 @@ static int may_delete(struct inode *dir, struct dentry *victim, bool isdir)return0;}+staticboolfsid_has_mapping(structuser_namespace*ns,structsuper_block*sb)+{+if(is_userns_visible(sb->s_iflags)){+if(!kuid_has_mapping(ns,current_kfsuid())||+!kgid_has_mapping(ns,current_kfsgid()))+returnfalse;+}elseif(!kfsuid_has_mapping(ns,current_fsuid())||+!kfsgid_has_mapping(ns,current_fsgid())){+returnfalse;+}++returntrue;+}+/* Check whether we can create an object with dentry child in directory*dir.*1.Wecan'tdoitifchildalreadyexists(openhasspecialtreatmentfor
From: Christian Brauner <hidden> Date: 2020-02-18 14:37:29
Switch set*id() calls to lookup fsids in the fsid mappings. If no fsid mappings
are setup the behavior is unchanged, i.e. fsids are looked up in the id
mappings.
A caller can only setid() to a given id if the id maps to a valid kid in
both the id and fsid maps of the caller's user namespace. This is always the
case when no id mappings and fsid mappings have been written. It is also always
the case when an id mapping has been written which includes the target id and
but no fsid mappings have been written. All non-fsid mapping aware workloads
will thus work just as before.
During setr*id() calls the kfsid is set to the keid corresponding to the eid
that is requested by userspace. If the requested eid is -1 the kfsid is reset
to the current keid. For the latter case this means we need to lookup the
corresponding userspace eid corresponding to the current keid in the id
mappings and translate this eid into the corresponding kfsid in the fsid
mappings.
We require that a user must have a valid fsid mapping for the target id. This
is consistent with how the setid calls work today without fsid mappings.
The kfsid to cleanly handle userns visible filesystem is set as before.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
- Christian Brauner [off-list ref]:
- set kfsid which is used when dealing with proc permission checking
/* v3 */
- Jann Horn [off-list ref]:
- Squash all set*id() patches into a single patch and move this to be the
last patch so we don't expose a half-done feature in the middle of this
series.
---
kernel/sys.c | 106 ++++++++++++++++++++++++++++++++++++++++-----------
1 file changed, 83 insertions(+), 23 deletions(-)
On Tue, Feb 18, 2020 at 3:37 PM Christian Brauner
[off-list ref] wrote:
Switch set*id() calls to lookup fsids in the fsid mappings. If no fsid mappings
are setup the behavior is unchanged, i.e. fsids are looked up in the id
mappings.
... but the "kfsgid" of the creds struct is translated by the normal
gid mapping...
+ new->fsgid = kfsgid;
... and the local "kfsgid" is stored into the "fsgid" member.
This is pretty hard to follow. Can you come up with some naming scheme
that is clearer and where one name is always used for the
normally-translated fsgid and another name is always used for the
specially-translated fsgid? E.g. something like "pfsgid" (with the "p"
standing for "process", because it uses the same id mappings as used
for process identities) for the IDs translated via the normal gid
mapping?
From: Christian Brauner <hidden> Date: 2020-02-18 14:37:52
ptrace_may_access() with PTRACE_MODE_FSCREDS is only used with proc and proc
wants to use the unmapped fsids.
Suggested-by: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
patch added
/* v3 */
unchanged
---
kernel/ptrace.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
From: Christian Brauner <hidden> Date: 2020-02-18 14:38:14
- Verify that fsid mappings cannot be written when if mappings have been
written already.
- Set up an id mapping and an fsid mapping, create a file and compare ids in
child and parent user namespace.
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
patch not present
/* v3 */
patch added
---
tools/testing/selftests/Makefile | 1 +
.../testing/selftests/user_namespace/Makefile | 11 +
.../selftests/user_namespace/test_fsid_map.c | 511 ++++++++++++++++++
3 files changed, 523 insertions(+)
create mode 100644 tools/testing/selftests/user_namespace/Makefile
create mode 100644 tools/testing/selftests/user_namespace/test_fsid_map.c
@@ -0,0 +1,511 @@+/* SPDX-License-Identifier: GPL-2.0 */++#define _GNU_SOURCE+#include<errno.h>+#include<fcntl.h>+#include<grp.h>+#include<inttypes.h>+#include<libgen.h>+#include<stdbool.h>+#include<sched.h>+#include<stdio.h>+#include<stdlib.h>+#include<string.h>+#include<linux/sched.h>+#include<sys/fsuid.h>+#include<sys/mount.h>+#include<sys/socket.h>+#include<sys/stat.h>+#include<sys/syscall.h>+#include<sys/types.h>+#include<sys/wait.h>+#include<unistd.h>++#include"../kselftest.h"+#include"../clone3/clone3_selftests.h"++staticintwait_for_pid(pid_tpid)+{+intstatus,ret;++again:+ret=waitpid(pid,&status,0);+if(ret==-1){+if(errno==EINTR)+gotoagain;++return-1;+}++if(!WIFEXITED(status))+return-1;++returnWEXITSTATUS(status);+}++staticintsetid_userns_root(void)+{+if(setuid(0))+return-1;+if(setgid(0))+return-1;++setfsuid(0);+setfsgid(0);++if(setfsuid(0))+return-1;++if(setfsgid(0))+return-1;++return0;+}++enumidmap_type{+UID_MAP,+GID_MAP,+FSUID_MAP,+FSGID_MAP,+};++staticssize_tread_nointr(intfd,void*buf,size_tcount)+{+ssize_tret;+again:+ret=read(fd,buf,count);+if(ret<0&&errno==EINTR)+gotoagain;++returnret;+}++staticssize_twrite_nointr(intfd,constvoid*buf,size_tcount)+{+ssize_tret;+again:+ret=write(fd,buf,count);+if(ret<0&&errno==EINTR)+gotoagain;++returnret;+}++staticintwrite_id_mapping(enumidmap_typetype,pid_tpid,constchar*buf,+size_tbuf_size)+{+intfd;+intret;+charpath[4096];++switch(type){+caseUID_MAP:+ret=snprintf(path,sizeof(path),"/proc/%d/uid_map",pid);+break;+caseGID_MAP:+ret=snprintf(path,sizeof(path),"/proc/%d/gid_map",pid);+break;+caseFSUID_MAP:+ret=snprintf(path,sizeof(path),"/proc/%d/fsuid_map",pid);+break;+caseFSGID_MAP:+ret=snprintf(path,sizeof(path),"/proc/%d/fsgid_map",pid);+break;+default:+return-1;+}+if(ret<0||ret>=sizeof(path))+return-E2BIG;++fd=open(path,O_WRONLY);+if(fd<0)+return-1;++ret=write_nointr(fd,buf,buf_size);+close(fd);+if(ret!=buf_size)+return-1;++return0;+}++constcharid_map[]="0 100000 100000";+#define id_map_size (sizeof(id_map) - 1)++constcharfsid_map[]="0 300000 100000";+#define fsid_map_size (sizeof(fsid_map) - 1)++intunix_send_fds_iov(intfd,int*sendfds,intnum_sendfds,structiovec*iov,+size_tiovlen)+{+char*cmsgbuf=NULL;+intret;+structmsghdrmsg;+structcmsghdr*cmsg=NULL;+size_tcmsgbufsize=CMSG_SPACE(num_sendfds*sizeof(int));++memset(&msg,0,sizeof(msg));++cmsgbuf=malloc(cmsgbufsize);+if(!cmsgbuf){+errno=ENOMEM;+return-1;+}++msg.msg_control=cmsgbuf;+msg.msg_controllen=cmsgbufsize;++cmsg=CMSG_FIRSTHDR(&msg);+cmsg->cmsg_level=SOL_SOCKET;+cmsg->cmsg_type=SCM_RIGHTS;+cmsg->cmsg_len=CMSG_LEN(num_sendfds*sizeof(int));++msg.msg_controllen=cmsg->cmsg_len;++memcpy(CMSG_DATA(cmsg),sendfds,num_sendfds*sizeof(int));++msg.msg_iov=iov;+msg.msg_iovlen=iovlen;++again:+ret=sendmsg(fd,&msg,MSG_NOSIGNAL);+if(ret<0)+if(errno==EINTR)+gotoagain;++free(cmsgbuf);+returnret;+}++staticintunix_send_fds(intfd,int*sendfds,intnum_sendfds,void*data,+size_tsize)+{+charbuf[1]={0};+structioveciov={+.iov_base=data?data:buf,+.iov_len=data?size:sizeof(buf),+};+returnunix_send_fds_iov(fd,sendfds,num_sendfds,&iov,1);+}++staticintunix_recv_fds_iov(intfd,int*recvfds,intnum_recvfds,+structiovec*iov,size_tiovlen)+{+char*cmsgbuf=NULL;+intret;+structmsghdrmsg;+structcmsghdr*cmsg=NULL;+size_tcmsgbufsize=CMSG_SPACE(sizeof(structucred))++CMSG_SPACE(num_recvfds*sizeof(int));++memset(&msg,0,sizeof(msg));++cmsgbuf=malloc(cmsgbufsize);+if(!cmsgbuf){+errno=ENOMEM;+return-1;+}++msg.msg_control=cmsgbuf;+msg.msg_controllen=cmsgbufsize;++msg.msg_iov=iov;+msg.msg_iovlen=iovlen;++again:+ret=recvmsg(fd,&msg,0);+if(ret<0){+if(errno==EINTR)+gotoagain;++gotoout;+}+if(ret==0)+gotoout;++/*+*IfSO_PASSCREDissetwewillalwaysgetaucredmessage.+*/+for(cmsg=CMSG_FIRSTHDR(&msg);cmsg;cmsg=CMSG_NXTHDR(&msg,cmsg)){+if(cmsg->cmsg_type!=SCM_RIGHTS)+continue;++memset(recvfds,-1,num_recvfds*sizeof(int));+if(cmsg&&+cmsg->cmsg_len==CMSG_LEN(num_recvfds*sizeof(int))&&+cmsg->cmsg_level==SOL_SOCKET)+memcpy(recvfds,CMSG_DATA(cmsg),num_recvfds*sizeof(int));+break;+}++out:+free(cmsgbuf);+returnret;+}++staticintunix_recv_fds(intfd,int*recvfds,intnum_recvfds,void*data,+size_tsize)+{+charbuf[1]={0};+structioveciov={+.iov_base=data?data:buf,+.iov_len=data?size:sizeof(buf),+};+returnunix_recv_fds_iov(fd,recvfds,num_recvfds,&iov,1);+}++staticboolhas_expected_owner(intfd,uid_tuid,gid_tgid)+{+intret;+structstats;+ret=fstat(fd,&s);+return!ret&&s.st_uid==uid&&s.st_gid==gid;+}++staticintmake_file_cmp_owner(uid_tuid,gid_tgid)+{+chartemplate[]=P_tmpdir"/.fsid_map_test_XXXXXX";+intfd;++fd=mkstemp(template);+if(fd<0)+return-1;+unlink(template);++if(!has_expected_owner(fd,uid,gid)){+close(fd);+return-1;+}++returnfd;+}++staticvoidtest_id_maps_imply_fsid_maps(void)+{+intfret=EXIT_FAILURE;+ssize_tret;+intfd=-EBADF;+pid_tpid;+intipc[2];+structclone_argsargs={+.flags=CLONE_NEWUSER,+.exit_signal=SIGCHLD,+};++ret=socketpair(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0,ipc);+if(ret<0)+ksft_exit_fail_msg("socketpair() failed\n");++pid=sys_clone3(&args,sizeof(args));+if(pid<0){+close(ipc[0]);+close(ipc[1]);+ksft_exit_fail_msg("clone3() failed\n");+}++if(pid==0){+intfd;+charbuf;++close(ipc[1]);++ret=read_nointr(ipc[0],&buf,1);+if(ret!=1)+ksft_exit_fail_msg("read_nointr() failed\n");++if(setid_userns_root())+ksft_exit_fail_msg("setid_userns_root() failed\n");++fd=make_file_cmp_owner(0,0);+if(fd<0)+ksft_exit_fail_msg("make_file_cmp_owner() failed\n");++if(unix_send_fds(ipc[0],&fd,1,NULL,0)<0)+ksft_exit_fail_msg("unix_send_fds() failed\n");++exit(EXIT_SUCCESS);+}++close(ipc[0]);++ret=write_id_mapping(UID_MAP,pid,id_map,id_map_size);+if(ret){+ksft_exit_fail_msg("unix_send_fds() failed\n");+gotokill_child;+}++/* Must fail since a uid mapping has already been written. */+ret=write_id_mapping(FSUID_MAP,pid,fsid_map,fsid_map_size);+if(ret==0){+ksft_exit_fail_msg("unix_send_fds() succeeded\n");+gotokill_child;+}++ret=write_id_mapping(GID_MAP,pid,id_map,id_map_size);+if(ret){+ksft_exit_fail_msg("unix_send_fds() failed\n");+gotokill_child;+}++/* Must fail since a gid mapping has already been written. */+ret=write_id_mapping(FSGID_MAP,pid,fsid_map,fsid_map_size);+if(ret==0){+ksft_exit_fail_msg("unix_send_fds() failed\n");+gotokill_child;+}++ret=write_nointr(ipc[1],"1",1);+if(ret!=1){+ksft_exit_fail_msg("write_nointr() failed\n");+gotokill_child;+}++if(unix_recv_fds(ipc[1],&fd,1,NULL,0)<0){+ksft_exit_fail_msg("unix_recv_fds() failed\n");+gotokill_child;+}++if(!has_expected_owner(fd,100000,100000)){+ksft_exit_fail_msg("has_expected_owner() failed\n");+gotokill_child;+}++fret=EXIT_SUCCESS;++wait_child:+ret=wait_for_pid(pid);+if(ret)+ksft_exit_fail_msg("wait_for_pid() failed\n");++if(fret==EXIT_SUCCESS)+return;+exit(fret);++kill_child:+kill(pid,SIGKILL);+exit(EXIT_FAILURE);+gotowait_child;+}++staticvoidtest_fsid_maps_basic(void)+{+intfret=EXIT_FAILURE;+ssize_tret;+intfd=-EBADF;+pid_tpid;+intipc[2];+structclone_argsargs={+.flags=CLONE_NEWUSER,+.exit_signal=SIGCHLD,+};++ret=socketpair(PF_LOCAL,SOCK_STREAM|SOCK_CLOEXEC,0,ipc);+if(ret<0)+ksft_exit_fail_msg("socketpair() failed\n");++pid=sys_clone3(&args,sizeof(args));+if(pid<0){+close(ipc[0]);+close(ipc[1]);+ksft_exit_fail_msg("clone3() failed\n");+}++if(pid==0){+intfd;+charbuf;++close(ipc[1]);++ret=read_nointr(ipc[0],&buf,1);+if(ret!=1)+ksft_exit_fail_msg("read_nointr() failed\n");++if(setid_userns_root())+ksft_exit_fail_msg("setid_userns_root() failed\n");++fd=make_file_cmp_owner(0,0);+if(fd<0)+ksft_exit_fail_msg("make_file_cmp_owner() failed\n");++if(unix_send_fds(ipc[0],&fd,1,NULL,0)<0)+ksft_exit_fail_msg("unix_send_fds() failed\n");++exit(EXIT_SUCCESS);+}++close(ipc[0]);++/* Must fail since a uid mapping has already been written. */+ret=write_id_mapping(FSUID_MAP,pid,fsid_map,fsid_map_size);+if(ret){+ksft_exit_fail_msg("unix_send_fds() failed\n");+gotokill_child;+}++ret=write_id_mapping(UID_MAP,pid,id_map,id_map_size);+if(ret){+ksft_exit_fail_msg("unix_send_fds() failed\n");+gotokill_child;+}++/* Must fail since a gid mapping has already been written. */+ret=write_id_mapping(FSGID_MAP,pid,fsid_map,fsid_map_size);+if(ret){+ksft_exit_fail_msg("unix_send_fds() failed\n");+gotokill_child;+}++ret=write_id_mapping(GID_MAP,pid,id_map,id_map_size);+if(ret){+ksft_exit_fail_msg("unix_send_fds() failed\n");+gotokill_child;+}++ret=write_nointr(ipc[1],"1",1);+if(ret!=1){+ksft_exit_fail_msg("write_nointr() failed\n");+gotokill_child;+}++if(unix_recv_fds(ipc[1],&fd,1,NULL,0)<0){+ksft_exit_fail_msg("unix_recv_fds() failed\n");+gotokill_child;+}++if(!has_expected_owner(fd,300000,300000)){+ksft_exit_fail_msg("has_expected_owner() failed\n");+gotokill_child;+}++fret=EXIT_SUCCESS;++wait_child:+ret=wait_for_pid(pid);+if(ret)+ksft_exit_fail_msg("wait_for_pid() failed\n");++if(fret==EXIT_SUCCESS)+return;+exit(fret);++kill_child:+kill(pid,SIGKILL);+exit(EXIT_FAILURE);+gotowait_child;+}++intmain(intargc,char*argv[])+{+if(getuid())+ksft_exit_skip("fsid mapping tests require root\n");++if(access("/proc/self/fsuid_map",F_OK))+ksft_exit_skip("fsid mappings not supported by this kernel\n");++test_clone3_supported();++test_id_maps_imply_fsid_maps();+test_fsid_maps_basic();++exit(EXIT_SUCCESS);+}
From: Christian Brauner <hidden> Date: 2020-02-18 14:38:38
Make sure that during suid/sgid binary execution we lookup the fsids in the
fsid mappings. If the kernel is compiled without fsid mappings or no fsid
mappings are setup the behavior is unchanged.
Assuming we have a binary in a given user namespace that is owned by 0:0 in the
given user namespace which appears as 300000:300000 on-disk in the initial user
namespace. Now assume we write an id mapping of 0 100000 100000 and an fsid
mapping for 0 300000 300000 in the user namespace. When we hit bprm_fill_uid()
during setid execution we will retrieve inode kuid=300000 and kgid=300000. We
first check whether there's an fsid mapping for these kids. In our scenario we
find that they map to fsuid=0 and fsgid=0 in the user namespace. Now we
translate them into kids in the id mapping. In our example they translate to
kuid=100000 and kgid=100000 which means the file will ultimately run as uid=0
and gid=0 in the user namespace and as uid=100000, gid=100000 in the initial
user namespace.
Let's alter the example and assume that there is an fsid mapping of 0 300000
300000 set up but no id mapping has been setup for the user namespace. In this
the last step of translating into a valid kid pair in the id mappings will fail
and we will behave as before and ignore the sid bits.
Cc: Jann Horn <jannh@google.com>
Signed-off-by: Christian Brauner <redacted>
---
/* v2 */
patch added
- Christian Brauner [off-list ref]:
- Make sure that bprm_fill_uid() handles fsid mappings.
/* v3 */
- Christian Brauner [off-list ref]:
- Fix commit message.
---
fs/exec.c | 25 +++++++++++++++++++------
1 file changed, 19 insertions(+), 6 deletions(-)
@@ -1551,18 +1552,30 @@ static void bprm_fill_uid(struct linux_binprm *bprm)inode_unlock(inode);/* We ignore suid/sgid if there are no mappings for them in the ns */-if(!kuid_has_mapping(bprm->cred->user_ns,uid)||-!kgid_has_mapping(bprm->cred->user_ns,gid))+if(!kfsuid_has_mapping(bprm->cred->user_ns,uid)||+!kfsgid_has_mapping(bprm->cred->user_ns,gid))return;+if(mode&S_ISUID){+euid=kfsuid_to_kuid(bprm->cred->user_ns,uid);+if(!uid_valid(euid))+return;+}++if((mode&(S_ISGID|S_IXGRP))==(S_ISGID|S_IXGRP)){+egid=kfsgid_to_kgid(bprm->cred->user_ns,gid);+if(!gid_valid(egid))+return;+}+if(mode&S_ISUID){bprm->per_clear|=PER_CLEAR_ON_SETID;-bprm->cred->euid=uid;+bprm->cred->euid=euid;}if((mode&(S_ISGID|S_IXGRP))==(S_ISGID|S_IXGRP)){bprm->per_clear|=PER_CLEAR_ON_SETID;-bprm->cred->egid=gid;+bprm->cred->egid=egid;}}
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2020-02-18 23:51:09
On Tue, 2020-02-18 at 15:33 +0100, Christian Brauner wrote:
In the usual case of running an unprivileged container we will have
setup an id mapping, e.g. 0 100000 100000. The on-disk mapping will
correspond to this id mapping, i.e. all files which we want to appear
as 0:0 inside the user namespace will be chowned to 100000:100000 on
the host. This works, because whenever the kernel needs to do a
filesystem access it will lookup the corresponding uid and gid in the
idmapping tables of the container. Now think about the case where we
want to have an id mapping of 0 100000 100000 but an on-disk mapping
of 0 300000 100000 which is needed to e.g. share a single on-disk
mapping with multiple containers that all have different id mappings.
This will be problematic. Whenever a filesystem access is requested,
the kernel will now try to lookup a mapping for 300000 in the id
mapping tables of the user namespace but since there is none the
files will appear to be owned by the overflow id, i.e. usually
65534:65534 or nobody:nogroup.
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping
exists, the corresponding files will have correct ownership.
So I did compile this up in order to run the shiftfs tests over it to
see how it coped with the various corner cases. However, what I find
is it simply fails the fsid reverse mapping in the setup. Trying to
use a simple uid of 0 100000 1000 and a fsid of 100000 0 1000 fails the
entry setuid(0) call because of this code:
long __sys_setuid(uid_t uid)
{
struct user_namespace *ns =
current_user_ns();
const struct cred *old;
struct cred *new;
int
retval;
kuid_t kuid;
kuid_t kfsuid;
kuid = make_kuid(ns, uid);
if
(!uid_valid(kuid))
return -EINVAL;
kfsuid = make_kfsuid(ns, uid);
if
(!uid_valid(kfsuid))
return -EINVAL;
which means you can't have a fsid mapping that doesn't have the same
domain as the uid mapping, meaning a reverse mapping isn't possible
because the range and domain have to be inverse and disjoint.
James
From: Christian Brauner <hidden> Date: 2020-02-19 12:28:12
On Tue, Feb 18, 2020 at 03:50:56PM -0800, James Bottomley wrote:
On Tue, 2020-02-18 at 15:33 +0100, Christian Brauner wrote:
quoted
In the usual case of running an unprivileged container we will have
setup an id mapping, e.g. 0 100000 100000. The on-disk mapping will
correspond to this id mapping, i.e. all files which we want to appear
as 0:0 inside the user namespace will be chowned to 100000:100000 on
the host. This works, because whenever the kernel needs to do a
filesystem access it will lookup the corresponding uid and gid in the
idmapping tables of the container. Now think about the case where we
want to have an id mapping of 0 100000 100000 but an on-disk mapping
of 0 300000 100000 which is needed to e.g. share a single on-disk
mapping with multiple containers that all have different id mappings.
This will be problematic. Whenever a filesystem access is requested,
the kernel will now try to lookup a mapping for 300000 in the id
mapping tables of the user namespace but since there is none the
files will appear to be owned by the overflow id, i.e. usually
65534:65534 or nobody:nogroup.
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping
exists, the corresponding files will have correct ownership.
So I did compile this up in order to run the shiftfs tests over it to
see how it coped with the various corner cases. However, what I find
is it simply fails the fsid reverse mapping in the setup. Trying to
use a simple uid of 0 100000 1000 and a fsid of 100000 0 1000 fails the
entry setuid(0) call because of this code:
This is easy to fix. But what's the exact use-case?
From: James Bottomley <James.Bottomley@HansenPartnership.com> Date: 2020-02-19 15:36:38
On Wed, 2020-02-19 at 13:27 +0100, Christian Brauner wrote:
On Tue, Feb 18, 2020 at 03:50:56PM -0800, James Bottomley wrote:
quoted
On Tue, 2020-02-18 at 15:33 +0100, Christian Brauner wrote:
[...]
quoted
quoted
With fsid mappings we can solve this by writing an id mapping of
0 100000 100000 and an fsid mapping of 0 300000 100000. On
filesystem access the kernel will now lookup the mapping for
300000 in the fsid mapping tables of the user namespace. And
since such a mapping exists, the corresponding files will have
correct ownership.
So I did compile this up in order to run the shiftfs tests over it
to see how it coped with the various corner cases. However, what I
find is it simply fails the fsid reverse mapping in the
setup. Trying to use a simple uid of 0 100000 1000 and a fsid of
100000 0 1000 fails the entry setuid(0) call because of this code:
This is easy to fix. But what's the exact use-case?
Well, the use case I'm looking to solve is the same one it's always
been: getting a deprivileged fake root in a user_ns to be able to write
an image at fsuid 0.
I don't think it's solvable in your current framework, although
allowing the domain to be disjoint might possibly hack around it. The
problem with the proposed framework is that there are no backshifts
from the filesystem view, there are only forward shifts to the
filesystem view. This means that to get your framework to write a
filesystem at fsuid 0 you have to have an identity map for fsuid. Which
I can do: I tested uid shift 0 100000 1000 and fsuid shift 0 0 1000.
It does all work, as you'd expect because the container has real fs
root not a fake root. And that's the whole problem: Firstly, I'm fs
root for any filesystem my userns can see, so any imprecision in
setting up the mount namespace of the container and I own your host and
secondly any containment break and I'm privileged with respect to the
fs uid wherever I escape to so I will likewise own your host.
The only way to keep containment is to have a zero fsuid inside the
container corresponding to a non-zero one outside. And the only way to
solve the imprecision in mount namespace issue is to strictly control
the entry point at which the writing at fsuid 0 becomes active.
James
On Tue, Feb 18, 2020 at 3:35 PM Christian Brauner
[off-list ref] wrote:
[...]
- Let the keyctl infrastructure only operate on kfsid which are always
mapped/looked up in the id mappings similar to what we do for
filesystems that have the same superblock visible in multiple user
namespaces.
This version also comes with minimal tests which I intend to expand in
the future.
From pings and off-list questions and discussions at Google Container
Security Summit there seems to be quite a lot of interest in this
patchset with use-cases ranging from layer sharing for app containers
and k8s, as well as data sharing between containers with different id
mappings. I haven't Cced all people because I don't have all the email
adresses at hand but I've at least added Phil now. :)
This is the implementation of shiftfs which was cooked up during lunch at
Linux Plumbers 2019 the day after the container's microconference. The
idea is a design-stew from Stéphane, Aleksa, Eric, and myself (and by
now also Jann.
Back then we all were quite busy with other work and couldn't really sit
down and implement it. But I took a few days last week to do this work,
including demos and performance testing.
This implementation does not require us to touch the VFS substantially
at all. Instead, we implement shiftfs via fsid mappings.
With this patch, it took me 20 mins to port both LXD and LXC to support
shiftfs via fsid mappings.
[...]
Can you please grep through the kernel for all uses of ->fsuid and
->fsgid and fix them up appropriately? Some cases I still see:
The SafeSetID LSM wants to enforce that you can only use CAP_SETUID to
gain the privileges of a specific set of IDs:
static int safesetid_task_fix_setuid(struct cred *new,
const struct cred *old,
int flags)
{
/* Do nothing if there are no setuid restrictions for our old RUID. */
if (setuid_policy_lookup(old->uid, INVALID_UID) == SIDPOL_DEFAULT)
return 0;
if (uid_permitted_for_cred(old, new->uid) &&
uid_permitted_for_cred(old, new->euid) &&
uid_permitted_for_cred(old, new->suid) &&
uid_permitted_for_cred(old, new->fsuid))
return 0;
/*
* Kill this process to avoid potential security vulnerabilities
* that could arise from a missing whitelist entry preventing a
* privileged process from dropping to a lesser-privileged one.
*/
force_sig(SIGKILL);
return -EACCES;
}
This could theoretically be bypassed through setfsuid() if the kuid
based on the fsuid mappings is permitted but the kuid based on the
normal mappings is not.
fs/coredump.c in suid dump mode uses "cred->fsuid = GLOBAL_ROOT_UID";
this should probably also fix up the other uid, even if there is no
scenario in which it would actually be used at the moment?
The netfilter xt_owner stuff makes packet filtering decisions based on
the ->fsuid; it might be better to filter on the ->kfsuid so that you
can filter traffic from different user namespaces differently?
audit_log_task_info() is doing "from_kuid(&init_user_ns, cred->fsuid)".
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 19:36:04
On Tue, Feb 18, 2020 at 03:33:46PM +0100, Christian Brauner wrote:
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping exists,
the corresponding files will have correct ownership.
So if I have
/proc/self/uid_map: 0 100000 100000
/proc/self/fsid_map: 1000 1000 1
1. If I read files from the rootfs which have host uid 101000, they
will appear as uid 100 to me?
2. If I read host files with uid 1000, they will appear as uid 1000 to me?
3. If I create a new file, as uid 1000, what will be the inode owning uid?
From: "Serge E. Hallyn" <serge@hallyn.com> Date: 2020-02-19 21:48:43
On Wed, Feb 19, 2020 at 01:35:58PM -0600, Serge E. Hallyn wrote:
On Tue, Feb 18, 2020 at 03:33:46PM +0100, Christian Brauner wrote:
quoted
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping exists,
the corresponding files will have correct ownership.
So if I have
/proc/self/uid_map: 0 100000 100000
/proc/self/fsid_map: 1000 1000 1
Oh, sorry. Your explanation in 20/25 i think set me straight, though I need
to think through a few more examples.
...
3. If I create a new file, as nsuid 1000, what will be the inode owning kuid?
(Note - I edited the quoted txt above to be more precise)
I'm still not quite clear on this. I believe the fsid mapping will take
precedence so it'll be uid 1000 ? Per mount behavior would be nice there,
but perhaps unwieldy.
On Wed, Feb 19, 2020 at 03:48:37PM -0600, Serge E. Hallyn wrote:
On Wed, Feb 19, 2020 at 01:35:58PM -0600, Serge E. Hallyn wrote:
quoted
On Tue, Feb 18, 2020 at 03:33:46PM +0100, Christian Brauner wrote:
quoted
With fsid mappings we can solve this by writing an id mapping of 0
100000 100000 and an fsid mapping of 0 300000 100000. On filesystem
access the kernel will now lookup the mapping for 300000 in the fsid
mapping tables of the user namespace. And since such a mapping exists,
the corresponding files will have correct ownership.
So if I have
/proc/self/uid_map: 0 100000 100000
/proc/self/fsid_map: 1000 1000 1
Oh, sorry. Your explanation in 20/25 i think set me straight, though I need
to think through a few more examples.
...
quoted
3. If I create a new file, as nsuid 1000, what will be the inode owning kuid?
(Note - I edited the quoted txt above to be more precise)
I'm still not quite clear on this. I believe the fsid mapping will take
precedence so it'll be uid 1000 ? Per mount behavior would be nice there,
but perhaps unwieldy.
The is_userns_visible() bits seems to be an attempt at understanding
what people would want per-mount, with a policy hard coded in the
kernel.
But maybe per-mount behavior can be solved more elegantly with shifted
bind mounts, so we can drop all that from this series, and ignore
per-mount settings here?
Tycho
From: Josef Bacik <josef@toxicpanda.com> Date: 2020-02-27 19:33:08
On 2/18/20 9:33 AM, Christian Brauner wrote:
Hey everyone,
This is v3 after (off- and online) discussions with Jann the following
changes were made:
- To handle nested user namespaces cleanly, efficiently, and with full
backwards compatibility for non fsid-mapping aware workloads we only
allow writing fsid mappings as long as the corresponding id mapping
type has not been written.
- Split the patch which adds the internal ability in
kernel/user_namespace to verify and write fsid mappings into tree
patches:
1. [PATCH v3 04/25] fsuidgid: add fsid mapping helpers
patch to implement core helpers for fsid translations (i.e.
make_kfs*id(), from_kfs*id{_munged}(), kfs*id_to_k*id(),
k*id_to_kfs*id()
2. [PATCH v3 05/25] user_namespace: refactor map_write()
patch to refactor map_write() in order to prepare for actual fsid
mappings changes in the following patch. (This should make it
easier to review.)
3. [PATCH v3 06/25] user_namespace: make map_write() support fsid mappings
patch to implement actual fsid mappings support in mape_write()
- Let the keyctl infrastructure only operate on kfsid which are always
mapped/looked up in the id mappings similar to what we do for
filesystems that have the same superblock visible in multiple user
namespaces.
This version also comes with minimal tests which I intend to expand in
the future.
From pings and off-list questions and discussions at Google Container
Security Summit there seems to be quite a lot of interest in this
patchset with use-cases ranging from layer sharing for app containers
and k8s, as well as data sharing between containers with different id
mappings. I haven't Cced all people because I don't have all the email
adresses at hand but I've at least added Phil now. :)
I put this into a kernel for our container guys to mess with in order to
validate it would actually be useful for real world uses. I've cc'ed the guy
who did all of the work in case you have specific questions.
Good news is the interface is acceptable, albeit apparently the whole user ns
interface sucks in general. But you haven't made it worse, so success!
But in testing it there appears to be a problem with tmpfs? Our applications
will use shared memory segments for certain things and it apparently breaks this
in interesting ways, it appears to not shift the UID appropriately on tmpfs.
This seems to be relatively straightforward to reproduce, but if you have
trouble let me know and I'll come up with a shell script that reproduces the
problem.
We are happy to continue testing these patches to make sure they're working in
our container setup, if you want to CC me on future submissions I can build them
for our internal testing and validate them as well. Thanks,
Josef