Message-ID: <564953d7ffb847365236a37639b81cbb7bca2aa6.camel@linux.ibm.com>
Date:   Mon, 28 Dec 2020 14:43:55 -0500
From:   Mimi Zohar <zohar@...ux.ibm.com>
To:     Casey Schaufler <casey@...aufler-ca.com>,
        casey.schaufler@...el.com, jmorris@...ei.org,
        linux-security-module@...r.kernel.org, selinux@...r.kernel.org
Cc:     linux-audit@...hat.com, keescook@...omium.org,
        john.johansen@...onical.com, penguin-kernel@...ove.sakura.ne.jp,
        paul@...l-moore.com, sds@...ho.nsa.gov,
        linux-kernel@...r.kernel.org, bpf@...r.kernel.org
Subject: Re: [PATCH v23 02/23] LSM: Create and manage the lsmblob data
 structure.

On Mon, 2020-12-28 at 11:22 -0800, Casey Schaufler wrote:
> On 12/28/2020 9:54 AM, Mimi Zohar wrote:
> > Hi Casey,
> >
> > On Fri, 2020-11-20 at 12:14 -0800, Casey Schaufler wrote:
> >> When more than one security module is exporting data to
> >> audit and networking sub-systems a single 32 bit integer
> >> is no longer sufficient to represent the data. Add a
> >> structure to be used instead.
> >>
> >> The lsmblob structure is currently an array of
> >> u32 "secids". There is an entry for each of the
> >> security modules built into the system that would
> >> use secids if active. The system assigns the module
> >> a "slot" when it registers hooks. If modules are
> >> compiled in but not registered there will be unused
> >> slots.
> >>
> >> A new lsm_id structure, which contains the name
> >> of the LSM and its slot number, is created. There
> >> is an instance for each LSM, which assigns the name
> >> and passes it to the infrastructure to set the slot.
> >>
> >> The audit rules data is expanded to use an array of
> >> security module data rather than a single instance.
> >> Because IMA uses the audit rule functions it is
> >> affected as well.
> > This patch is quite large, even without the audit rule change.  I would
> > limit this patch to the new lsm_id structure changes.  The audit rule
> > change should be broken out as a separate patch so that the audit
> > changes aren't hidden.
> 
> Breaking up the patch in any meaningful way would require
> scaffolding code that is as extensive and invasive as the
> final change. I can do that if you really need it, but it
> won't be any easier to read.

Hidden in this patch is the new behavior of security_audit_rule_init(),
security_audit_rule_free(), and security_audit_rule_match().  My
concern is with label collision.  Details are in a subsequent post. 
Can an LSM prevent label collision?

> 
> > In addition, here are a few high level nits:
> > - The (patch description) body of the explanation, line wrapped at 75
> > columns, which will be copied to the permanent changelog to describe
> > this patch. (Refer  Documentation/process/submitting-patches.rst.)
> 
> Will fix.
> 
> > - The brief kernel-doc descriptions should not have a trailing period. 
> > Nor should kernel-doc variable definitions have a trailing period. 
> > Example(s) inline below.  (The existing kernel-doc is mostly correct.)
> 
> Will fix.
> 
> > - For some reason existing comments that span multiple lines aren't
> > formatted properly.   In those cases, where there is another change,
> > please fix the comment and function description.
> 
> Can you give an example? There are multiple comment styles
> used in the various components.

Never mind.  All three examples are in tomoyo.

> I don't see any comments on the ima code changes. I really
> don't want to spin a new patch set that does nothing but change
> two periods in comments only to find out two months from now
> that the code changes are completely borked. I really don't
> want to go through the process of breaking up the patch that has
> been widely Acked if there's no reason to expect it would require
> significant work otherwise.

Understood.

Powered by blists - more mailing lists