From: Mimi Zohar <zohar@linux.ibm.com> To: Casey Schaufler <casey@schaufler-ca.com>, casey.schaufler@intel.com, jmorris@namei.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Cc: linux-audit@redhat.com, keescook@chromium.org, john.johansen@canonical.com, penguin-kernel@i-love.sakura.ne.jp, paul@paul-moore.com, sds@tycho.nsa.gov, linux-kernel@vger.kernel.org, bpf@vger.kernel.org Subject: Re: [PATCH v23 02/23] LSM: Create and manage the lsmblob data structure. Date: Tue, 29 Dec 2020 14:16:41 -0500 [thread overview] Message-ID: <ed9e0dbb48b712a371d3ca4ea5dfa5121d2f98df.camel@linux.ibm.com> (raw) In-Reply-To: <10442dd5-f16e-3ca4-c233-7394a11cbbad@schaufler-ca.com> On Tue, 2020-12-29 at 10:46 -0800, Casey Schaufler wrote: > >>>>>> -int security_audit_rule_match(u32 secid, u32 field, u32 op, void *lsmrule) > >>>>>> +int security_audit_rule_match(u32 secid, u32 field, u32 op, void **lsmrule) > >>>>>> { > >>>>>> - return call_int_hook(audit_rule_match, 0, secid, field, op, lsmrule); > >>>>>> + struct security_hook_list *hp; > >>>>>> + int rc; > >>>>>> + > >>>>>> + hlist_for_each_entry(hp, &security_hook_heads.audit_rule_match, list) { > >>>>>> + if (WARN_ON(hp->lsmid->slot < 0 || hp->lsmid->slot >= lsm_slot)) > >>>>>> + continue; > >>>>>> + rc = hp->hook.audit_rule_match(secid, field, op, > >>>>>> + &lsmrule[hp->lsmid->slot]); > >>>>>> + if (rc) > >>>>>> + return rc; > >>>>> Suppose that there is an IMA dont_measure or dont_appraise rule, if one > >>>>> LSM matches, then this returns true, causing any measurement or > >>>>> integrity verification to be skipped. > >>>> Yes, that is correct. Like the audit system, you're doing a string based > >>>> lookup, which pretty well has to work this way. I have proposed compound > >>>> label specifications in the past, but even if we accepted something like > >>>> "apparmor=dates,selinux=figs" we'd still have to be compatible with the > >>>> old style inputs. > >>>> > >>>>> Sample policy rules: > >>>>> dont_measure obj_type=foo_log > >>>>> dont_appraise obj_type=foo_log > >>> IMA could extend the existing policy rules like "lsm=[selinux] | > >>> [smack] | [apparmor]", but that assumes that the underlying > >>> infrastructure supports it. > >> Yes, but you would still need rational behavior in the > >> case where someone has old IMA policy rules. > > From an IMA perspective, allowing multiple LSMs to define the same > > policy label is worse than requiring the label be constrained to a > > particular LSM. > > Just to be sure we're talking about the same thing, > the case I'm referring to is something like a file with > two extended attributes: > > security.apparmor MacAndCheese > security.SMACK64 MacAndCheese > > and an IMA rule that says > > dont_measure obj_type=MacAndCheese > > In this case the dont_measure will be applied to both. > On the other hand, > > security.apparmor MacAndCheese > security.SMACK64 FranksAndBeans > > would also apply the rule to both, which is not > what you want. Unfortunately, there is no way to > differentiate which LSM hit the rule. > > So now I'm a little confused. The case where both LSMs > use the same label looks like it works right, where the > case where they're different doesn't. I'm more concerned about multiple LSMs using the same label. The label's meaning is LSM specific. > > I'm beginning to think that identifying which LSMs matched > a rule (it may be none, either or both) is the right solution. > I don't think that audit is as sensitive to this. If the label's meaning is LSM specific, then the rule needs to be LSM specific.
WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com> To: Casey Schaufler <casey@schaufler-ca.com>, casey.schaufler@intel.com, jmorris@namei.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org Cc: john.johansen@canonical.com, linux-kernel@vger.kernel.org, linux-audit@redhat.com, bpf@vger.kernel.org, sds@tycho.nsa.gov Subject: Re: [PATCH v23 02/23] LSM: Create and manage the lsmblob data structure. Date: Tue, 29 Dec 2020 14:16:41 -0500 [thread overview] Message-ID: <ed9e0dbb48b712a371d3ca4ea5dfa5121d2f98df.camel@linux.ibm.com> (raw) In-Reply-To: <10442dd5-f16e-3ca4-c233-7394a11cbbad@schaufler-ca.com> On Tue, 2020-12-29 at 10:46 -0800, Casey Schaufler wrote: > >>>>>> -int security_audit_rule_match(u32 secid, u32 field, u32 op, void *lsmrule) > >>>>>> +int security_audit_rule_match(u32 secid, u32 field, u32 op, void **lsmrule) > >>>>>> { > >>>>>> - return call_int_hook(audit_rule_match, 0, secid, field, op, lsmrule); > >>>>>> + struct security_hook_list *hp; > >>>>>> + int rc; > >>>>>> + > >>>>>> + hlist_for_each_entry(hp, &security_hook_heads.audit_rule_match, list) { > >>>>>> + if (WARN_ON(hp->lsmid->slot < 0 || hp->lsmid->slot >= lsm_slot)) > >>>>>> + continue; > >>>>>> + rc = hp->hook.audit_rule_match(secid, field, op, > >>>>>> + &lsmrule[hp->lsmid->slot]); > >>>>>> + if (rc) > >>>>>> + return rc; > >>>>> Suppose that there is an IMA dont_measure or dont_appraise rule, if one > >>>>> LSM matches, then this returns true, causing any measurement or > >>>>> integrity verification to be skipped. > >>>> Yes, that is correct. Like the audit system, you're doing a string based > >>>> lookup, which pretty well has to work this way. I have proposed compound > >>>> label specifications in the past, but even if we accepted something like > >>>> "apparmor=dates,selinux=figs" we'd still have to be compatible with the > >>>> old style inputs. > >>>> > >>>>> Sample policy rules: > >>>>> dont_measure obj_type=foo_log > >>>>> dont_appraise obj_type=foo_log > >>> IMA could extend the existing policy rules like "lsm=[selinux] | > >>> [smack] | [apparmor]", but that assumes that the underlying > >>> infrastructure supports it. > >> Yes, but you would still need rational behavior in the > >> case where someone has old IMA policy rules. > > From an IMA perspective, allowing multiple LSMs to define the same > > policy label is worse than requiring the label be constrained to a > > particular LSM. > > Just to be sure we're talking about the same thing, > the case I'm referring to is something like a file with > two extended attributes: > > security.apparmor MacAndCheese > security.SMACK64 MacAndCheese > > and an IMA rule that says > > dont_measure obj_type=MacAndCheese > > In this case the dont_measure will be applied to both. > On the other hand, > > security.apparmor MacAndCheese > security.SMACK64 FranksAndBeans > > would also apply the rule to both, which is not > what you want. Unfortunately, there is no way to > differentiate which LSM hit the rule. > > So now I'm a little confused. The case where both LSMs > use the same label looks like it works right, where the > case where they're different doesn't. I'm more concerned about multiple LSMs using the same label. The label's meaning is LSM specific. > > I'm beginning to think that identifying which LSMs matched > a rule (it may be none, either or both) is the right solution. > I don't think that audit is as sensitive to this. If the label's meaning is LSM specific, then the rule needs to be LSM specific. -- Linux-audit mailing list Linux-audit@redhat.com https://www.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2020-12-29 19:17 UTC|newest] Thread overview: 84+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <20201120201507.11993-1-casey.ref@schaufler-ca.com> 2020-11-20 20:14 ` [PATCH v22 00/23] LSM: Module stacking for AppArmor Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 01/23] LSM: Infrastructure management of the sock security Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 02/23] LSM: Create and manage the lsmblob data structure Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-12-28 17:54 ` Mimi Zohar 2020-12-28 17:54 ` Mimi Zohar 2020-12-28 19:22 ` Casey Schaufler 2020-12-28 19:22 ` Casey Schaufler 2020-12-28 19:43 ` Mimi Zohar 2020-12-28 19:43 ` Mimi Zohar 2020-12-28 19:24 ` Mimi Zohar 2020-12-28 19:24 ` Mimi Zohar 2020-12-28 20:06 ` Casey Schaufler 2020-12-28 20:06 ` Casey Schaufler 2020-12-28 22:14 ` Mimi Zohar 2020-12-28 22:14 ` Mimi Zohar 2020-12-28 23:20 ` Casey Schaufler 2020-12-28 23:20 ` Casey Schaufler 2020-12-29 1:53 ` Mimi Zohar 2020-12-29 1:53 ` Mimi Zohar 2020-12-29 13:53 ` Mimi Zohar 2020-12-29 13:53 ` Mimi Zohar 2020-12-29 18:46 ` Casey Schaufler 2020-12-29 18:46 ` Casey Schaufler 2020-12-29 19:16 ` Mimi Zohar [this message] 2020-12-29 19:16 ` Mimi Zohar 2020-11-20 20:14 ` [PATCH v23 03/23] LSM: Use lsmblob in security_audit_rule_match Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 04/23] LSM: Use lsmblob in security_kernel_act_as Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 05/23] LSM: Use lsmblob in security_secctx_to_secid Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 06/23] LSM: Use lsmblob in security_secid_to_secctx Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 07/23] LSM: Use lsmblob in security_ipc_getsecid Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 08/23] LSM: Use lsmblob in security_task_getsecid Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 09/23] LSM: Use lsmblob in security_inode_getsecid Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 10/23] LSM: Use lsmblob in security_cred_getsecid Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 11/23] IMA: Change internal interfaces to use lsmblobs Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 12/23] LSM: Specify which LSM to display Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 13/23] LSM: Ensure the correct LSM context releaser Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 14/23] LSM: Use lsmcontext in security_secid_to_secctx Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:14 ` [PATCH v23 15/23] LSM: Use lsmcontext in security_inode_getsecctx Casey Schaufler 2020-11-20 20:14 ` Casey Schaufler 2020-11-20 20:15 ` [PATCH v23 16/23] LSM: security_secid_to_secctx in netlink netfilter Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler 2020-11-20 20:15 ` [PATCH v23 17/23] NET: Store LSM netlabel data in a lsmblob Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler 2020-11-20 20:15 ` [PATCH v23 18/23] LSM: Verify LSM display sanity in binder Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler 2020-11-20 20:15 ` [PATCH v23 19/23] audit: add support for non-syscall auxiliary records Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler 2020-11-20 23:06 ` kernel test robot 2020-11-20 23:06 ` kernel test robot 2020-11-20 23:06 ` kernel test robot 2020-11-21 0:36 ` kernel test robot 2020-11-21 0:36 ` kernel test robot 2020-11-21 7:36 ` kernel test robot 2020-11-21 7:36 ` kernel test robot 2020-11-21 7:36 ` kernel test robot 2020-11-20 20:15 ` [PATCH v23 20/23] Audit: Add new record for multiple process LSM attributes Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler 2020-11-20 22:51 ` kernel test robot 2020-11-20 22:51 ` kernel test robot 2020-11-20 22:51 ` kernel test robot 2020-11-21 0:02 ` kernel test robot 2020-11-21 0:02 ` kernel test robot 2020-11-21 0:02 ` kernel test robot 2020-11-20 20:15 ` [PATCH v23 21/23] Audit: Add a new record for multiple object " Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler 2020-11-20 20:15 ` [PATCH v23 22/23] LSM: Add /proc attr entry for full LSM context Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler 2020-11-20 20:15 ` [PATCH v23 23/23] AppArmor: Remove the exclusive flag Casey Schaufler 2020-11-20 20:15 ` Casey Schaufler
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=ed9e0dbb48b712a371d3ca4ea5dfa5121d2f98df.camel@linux.ibm.com \ --to=zohar@linux.ibm.com \ --cc=bpf@vger.kernel.org \ --cc=casey.schaufler@intel.com \ --cc=casey@schaufler-ca.com \ --cc=jmorris@namei.org \ --cc=john.johansen@canonical.com \ --cc=keescook@chromium.org \ --cc=linux-audit@redhat.com \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=paul@paul-moore.com \ --cc=penguin-kernel@i-love.sakura.ne.jp \ --cc=sds@tycho.nsa.gov \ --cc=selinux@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.