Messages in this thread | | | Date | Wed, 1 Dec 2021 17:09:05 -0500 | Subject | Re: [RFC 20/20] ima: Setup securityfs_ns for IMA namespace | From | Stefan Berger <> |
| |
On 12/1/21 17:01, James Bottomley wrote: > On Wed, 2021-12-01 at 16:34 -0500, Stefan Berger wrote: >> On 12/1/21 16:11, James Bottomley wrote: >>> On Wed, 2021-12-01 at 15:25 -0500, Stefan Berger wrote: >>>> On 12/1/21 14:21, James Bottomley wrote: >>>>> 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 am surprised you get this mapping even after commenting the >>>> permission adjustments... it doesn't work for me when I comment >>>> them >>>> out: >>>> >>>> [stefanb@ima-ns-dev rootfs]$ unshare -r --user --mount >>>> [root@ima-ns-dev rootfs]# mount -t securityfs_ns none >>>> /sys/kernel/security/ >>>> [root@ima-ns-dev rootfs]# cd /sys/kernel/security/ima/ >>>> [root@ima-ns-dev ima]# ls -l >>>> total 0 >>>> -r--r-----. 1 nobody nobody 0 Dec 1 15:20 >>>> ascii_runtime_measurements >>>> -r--r-----. 1 nobody nobody 0 Dec 1 15:20 >>>> binary_runtime_measurements >>>> -rw-------. 1 nobody nobody 0 Dec 1 15:20 policy >>>> -r--r-----. 1 nobody nobody 0 Dec 1 15:20 >>>> runtime_measurements_count >>>> -r--r-----. 1 nobody nobody 0 Dec 1 15:20 violations >>>> [root@ima-ns-dev ima]# cat /proc/self/uid_map >>>> 0 1000 1 >>>> [root@ima-ns-dev ima]# cat /proc/self/gid_map >>>> 0 1000 1 >>>> >>>> The initialization of securityfs and setup of files and >>>> directories >>>> happens at the same time as the IMA namespace is created. At this >>>> time there are no user mappings available, so that's why I need >>>> to >>>> make the adjustments 'late'. >>> There is one other possible difference: To get the correct >>> s_user_ns >> I am currently wondering why I cannot re-create your setup while >> disabling the remapping... > OK, I think I figured it out. When I applied your patches, it was on > top of my existing ones, so I had to massage them a bit. > > Your problem is the securityfs inode creation is triggered inside > create_user_ns, which means it happens *before* ushare writes to the > proc/self/uid_map file, so the securityfs_inodes are always created on > an empty mapping and i_write_uid always sets the inode uid to -1.
Right, the initialization of the filesystem is quite early.
> > I don't see this because my setup for everything is triggered off the > first use of the IMA namespace. You'd need to have some type of lazy > setup of the inodes as well to give unshare time to install the uid/gid > mappings.
What could trigger that? A callback while mounting - but I am not sure where to hook into then. What is your mechanisms to trigger as the 'first use of the IMA namespace'? What is 'use' here?
Stefan
> > James > >
| |