lkml.org 
[lkml]   [2021]   [Dec]   [1]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC 20/20] ima: Setup securityfs_ns for IMA namespace
From
Date
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@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.

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




\
 
 \ /
  Last update: 2021-12-01 20:22    [W:0.064 / U:0.208 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site