Message-ID: <b8c21064-05f3-91a9-d23c-0417f046f4cc@linux.ibm.com>
Date:   Wed, 1 Dec 2021 17:09:05 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.2.0
Subject: Re: [RFC 20/20] ima: Setup securityfs_ns for IMA namespace
Content-Language: en-US
To:     jejb@linux.ibm.com, linux-integrity@vger.kernel.org
Cc:     zohar@linux.ibm.com, serge@hallyn.com,
        christian.brauner@ubuntu.com, containers@lists.linux.dev,
        dmitry.kasatkin@gmail.com, ebiederm@xmission.com,
        krzysztof.struczynski@huawei.com, roberto.sassu@huawei.com,
        mpeters@redhat.com, lhinds@redhat.com, lsturman@redhat.com,
        puiterwi@redhat.com, jamjoom@us.ibm.com,
        linux-kernel@vger.kernel.org, paul@paul-moore.com, rgb@redhat.com,
        linux-security-module@vger.kernel.org, jmorris@namei.org
References: <20211130160654.1418231-1-stefanb@linux.ibm.com>
 <20211130160654.1418231-21-stefanb@linux.ibm.com>
 <6599ac61289e3316bff53602a0bc5970133251aa.camel@linux.ibm.com>
 <f2113d60-49d3-2e2d-7dbe-b831035f96a1@linux.ibm.com>
 <f5e3101e8dee2aa0064e7b68992afe0143e22058.camel@linux.ibm.com>
 <9631d4b3-15f6-46f1-6441-98c1192be6b4@linux.ibm.com>
 <c6d7b9363991b80b2f55bbdb7e44c18ea45489da.camel@linux.ibm.com>
 <8d7b6d47-9001-1f47-bce8-e7fae28fafcf@linux.ibm.com>
 <38458eee904713824b85a2dcef248e752634f67c.camel@linux.ibm.com>
From:   Stefan Berger <stefanb@linux.ibm.com>
In-Reply-To: <38458eee904713824b85a2dcef248e752634f67c.camel@linux.ibm.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


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