Message-ID: <175831be-4c26-bd86-27c1-dd822514f06f@linux.ibm.com>
Date:   Mon, 27 Dec 2021 12:29:42 -0500
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.3.0
Subject: Re: [PATCH v7 00/14] ima: Namespace IMA with audit support in IMA-ns
Content-Language: en-US
To:     Christian Brauner <christian.brauner@ubuntu.com>
Cc:     Stefan Berger <stefanb@linux.vnet.ibm.com>,
        linux-integrity@vger.kernel.org, zohar@linux.ibm.com,
        serge@hallyn.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, jejb@linux.ibm.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: <20211216054323.1707384-1-stefanb@linux.vnet.ibm.com>
 <20211216125027.fte6625wu5vxkjpi@wittgenstein>
 <07c28891-5ac1-3c0d-bb67-cc49aca0aae2@linux.ibm.com>
 <20211217100659.2iah5prshavjk6v6@wittgenstein>
From:   Stefan Berger <stefanb@linux.ibm.com>
In-Reply-To: <20211217100659.2iah5prshavjk6v6@wittgenstein>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Precedence: bulk


On 12/17/21 05:06, Christian Brauner wrote:
> On Thu, Dec 16, 2021 at 04:00:40PM -0500, Stefan Berger wrote:
>>
>> But that could still mean a lot of contention on iint->mutex since this
>> lock is global, i.e. in this context: for all ima namespaces. You might
>> want to consider coming up with some rough ideas for how to solve this
>> _if_ this becomes a problem in the future.
>>
>> The plan is that each IMA namespace will have its own rbtree with its own
>> set of iints. We cannot do it all at the same time, so this will take while
>> until things can be completely moved over into a per-IMA namespace rbtree
>> and each IMA namespace becomes fully independent.
> Ok, good to hear that you have already thought about that.


Well, yes, we thought about it. However, as far as I can look ahead we 
cannot get rid of the iint->mutex:

Obviously we have to organize the data structures where IMA is recording 
what it has done with a file/inode in such a way that each namespace can 
efficiently determine whether it needs to audit/measure/appraise a file 
or re-audit/re-measure/re-appraise it after file modification. The 
organization of these data structures also has to reflect the fact that 
files can be shared between IMA namespaces via setns() on mount 
namespaces or shared files or shared mount namespaces between containers 
etc.. So, the first thing we do already is move audit-related flags into 
what is called the ns_status (namespace status) structure that are kept 
in a per-IMA namespace rbtree. This allows IMA to remember that a file 
was already audited and it doesn't need to audit it again. The lookup 
via rbtree is quick: O(log(n).

Unfortunately the previous series had a bug so that files were not 
re-audited after they were modified. I fixed this now in the new series 
(upcoming v8) by connecting each ns_status also to a list. This list 
starts in the global inode integrity cache (the iint rbtree) where each 
inode that any IMA namespace accessed has an iint entry today. The lists 
start on the iint entries representing inodes.  When files are deleted 
or modified or xattrs are modified then all IMA namespaces need to 
re-audit/re-measure/re-appraise the file (depending on policy) and for 
this we have to reset flags across all the IMA namespaces by walking the 
list of ns_status entries. The organization via iint rbtree and 
ns_status list allows for quick lookup of the inode where the 
modification happened and quick reset of the flags: O(log(n)) + O(n). 
This is better than having to search all namespaces to reset the flags 
(O(log(n) * n) if there was no list.


     Stefan