On Wed, 2021-12-01 at 13:11 -0500, Stefan Berger wrote:
On 12/1/21 12:56, James Bottomley wrote:[...]
I tried this with runc and a user namespace active mapping uid 1000So I applied your patches with the permission shift commented out and
on the host to uid 0 in the container. There I run into the problem
that all of the files and directories without the above work-around
are mapped to 'nobody', just like all the files in sysfs in this case
are also mapped to nobody. This code resolved the issue.
instrumented inode_alloc() to see where it might be failing and I
actually find it all works as expected for me:
ejb@testdeb:~> unshare -r --user --mount --ima
root@testdeb:~# mount -t securityfs_ns none /sys/kernel/security
root@testdeb:~# ls -l /sys/kernel/security/ima/
total 0
-r--r----- 1 root root 0 Dec 1 19:11 ascii_runtime_measurements
-r--r----- 1 root root 0 Dec 1 19:11 binary_runtime_measurements
-rw------- 1 root root 0 Dec 1 19:11 policy
-r--r----- 1 root root 0 Dec 1 19:11 runtime_measurements_count
-r--r----- 1 root root 0 Dec 1 19:11 violations
I think your problem is something to do with how runc is installing the
uid/gid mappings. If it's installing them after the security_ns inodes
are created then they get the -1 value (because no mappings exist in
s_user_ns). I can even demonstrate this by forcing unshare to enter
the IMA namespace before writing the mapping values and I'll see
"nobody nogroup" above like you do.