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.
