[RFC 20/20] ima: Setup securityfs_ns for IMA namespace

[James Bottomley]

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 1000
> 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.

So I applied your patches with the permission shift commented out and
instrumented inode_alloc() to see where it might be failing and I
actually find it all works as expected for me:

ejb at testdeb:~> unshare -r --user --mount --ima
root at testdeb:~# mount -t securityfs_ns none /sys/kernel/security
root at 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.

I also see the instrumentation telling me that i_write_uid() is mapping
back to 1000 in the former case and -1 in the latter.

James