linux-kernel - Re: [PATCH v9 08/23] ima: Move measurement list related variables into ima

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aff500e2-b52d-c153-8d23-f9b84e6bb182@linux.ibm.com>
Date:   Fri, 28 Jan 2022 09:06:51 -0500
From:   Stefan Berger <stefanb@...ux.ibm.com>
To:     Mimi Zohar <zohar@...ux.ibm.com>,
        Christian Brauner <brauner@...nel.org>,
        Stefan Berger <stefanb@...ux.vnet.ibm.com>
Cc:     linux-integrity@...r.kernel.org, serge@...lyn.com,
        christian.brauner@...ntu.com, containers@...ts.linux.dev,
        dmitry.kasatkin@...il.com, ebiederm@...ssion.com,
        krzysztof.struczynski@...wei.com, roberto.sassu@...wei.com,
        mpeters@...hat.com, lhinds@...hat.com, lsturman@...hat.com,
        puiterwi@...hat.com, jejb@...ux.ibm.com, jamjoom@...ibm.com,
        linux-kernel@...r.kernel.org, paul@...l-moore.com, rgb@...hat.com,
        linux-security-module@...r.kernel.org, jmorris@...ei.org
Subject: Re: [PATCH v9 08/23] ima: Move measurement list related variables
 into ima_namespace


On 1/27/22 16:48, Mimi Zohar wrote:
> On Wed, 2022-01-26 at 17:23 -0500, Stefan Berger wrote:
>> On 1/26/22 04:21, Christian Brauner wrote:
>>> On Tue, Jan 25, 2022 at 05:46:30PM -0500, Stefan Berger wrote:
>>>> From: Stefan Berger <stefanb@...ux.ibm.com>
>>>>
>>>> Move measurement list related variables into the ima_namespace. This way
>>>> a front-end like securityfs can show the measurement list inside an IMA
>>>> namespace.
>>>>
>>>> Signed-off-by: Stefan Berger <stefanb@...ux.ibm.com>
>>>> ---
>>>>    security/integrity/ima/ima.h             |  5 +++--
>>>>    security/integrity/ima/ima_fs.c          |  6 ++++--
>>>>    security/integrity/ima/ima_init_ima_ns.c |  5 +++++
>>>>    security/integrity/ima/ima_kexec.c       | 12 ++++++-----
>>>>    security/integrity/ima/ima_queue.c       | 27 +++++++++++-------------
>>>>    5 files changed, 31 insertions(+), 24 deletions(-)
>>>>
>>>> diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
>>>> index 340a59174670..45706836a77b 100644
>>>> --- a/security/integrity/ima/ima.h
>>>> +++ b/security/integrity/ima/ima.h
>>>> @@ -106,7 +106,6 @@ struct ima_queue_entry {
>>>>    	struct list_head later;		/* place in ima_measurements list */
>>>>    	struct ima_template_entry *entry;
>>>>    };
>>>> -extern struct list_head ima_measurements;	/* list of all measurements */
>>>>    
>>>>    /* Some details preceding the binary serialized measurement list */
>>>>    struct ima_kexec_hdr {
>>>> @@ -136,6 +135,8 @@ struct ima_namespace {
>>>>    	struct ima_rule_entry *arch_policy_entry;
>>>>    
>>>>    	struct ima_h_table ima_htable;
>>>> +	struct list_head ima_measurements;	/* list of all measurements */
>>>> +	unsigned long binary_runtime_size;	/* used by init_ima_ns */
>>>>    } __randomize_layout;
>>> Moving this into struct imans seems sane to me but I'm not going to ack
>>> it because I don't have enough knowledge to guarantee that this code
>>> will only run for init_ima_ns. I'll leave that to Mimi.
> Moving the ima_measurements to the ima_namespace is needed for
> namespacing the IMA measurement list (next stage).  I think moving it
> now is fine.
And besides that we can now already how an empty measurement list 
without having to special case the code.
>
>> The code modifying binary_runtime_size may do this for all IMA
>> namespaces but the esulting value of binary_runtime_size may only
>> matter in init_ima_ns (not 100% sure, but Mimi seems to say so). Moving
>> it into ima_namespace rather than special-casing the code keeps the code
>> readable.
> Right, there are other changes like moving the binary_runtime_size to
> the namespace, which aren't needed, but are being done, I guess, for
> aesthetics.  The binary_runtime_size is only used for allocating the
> memory needed for carrying the measurement list across kexec.  Anything
> related to carrying or restoring the measurement list across kexec is
> limited to ima_init_ns.
>
>> There are also some case in the code that may do something like this:
>>
>> if (ns == &init_ima_ns)
>>
>>       foo = xyz;
>>
>> Those will go away when foo is moved into the namespace and then it
>> becomes ns->foo = xyz, which is much saner for readability but
>> unavoidable for some variables at this stage.
> Since binary_runtime_size is limited to the ima_init_ns, should it be
> conditional?

Moving it into ima_namespace keeps the code clean from these kind of 
constructs above. I would move it... The less of these constructs are 
there the less confusing it is, IMO. But ymmv.



>
> thanks,
>
> Mimi
>