From: Paul Moore <paul@paul-moore.com> To: Roberto Sassu <roberto.sassu@huaweicloud.com> Cc: mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com, zohar@linux.ibm.com, dmitry.kasatkin@gmail.com, jmorris@namei.org, serge@hallyn.com, stephen.smalley.work@gmail.com, eparis@parisplace.org, casey@schaufler-ca.com, ocfs2-devel@oss.oracle.com, reiserfs-devel@vger.kernel.org, linux-integrity@vger.kernel.org, linux-security-module@vger.kernel.org, selinux@vger.kernel.org, linux-kernel@vger.kernel.org, keescook@chromium.org, nicolas.bouchinet@clip-os.org, Roberto Sassu <roberto.sassu@huawei.com> Subject: Re: [PATCH v8 4/6] security: Allow all LSMs to provide xattrs for inode_init_security hook Date: Tue, 28 Mar 2023 16:19:55 -0400 [thread overview] Message-ID: <CAHC9VhRNWeZtxain_Hi-EfS49Vac8_vg7KRRyV4a9Sq3XPhZsg@mail.gmail.com> (raw) In-Reply-To: <1e08006f9011efa48deaf656c358ca3d438b9768.camel@huaweicloud.com> On Tue, Mar 28, 2023 at 3:47 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > On Mon, 2023-03-27 at 17:02 -0400, Paul Moore wrote: > > On Mon, Mar 27, 2023 at 3:30 AM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > On Fri, 2023-03-24 at 17:39 -0400, Paul Moore wrote: > > > > On Fri, Mar 24, 2023 at 9:26 AM Roberto Sassu > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > On Fri, 2023-03-24 at 11:18 +0100, Roberto Sassu wrote: > > > > > > On Thu, 2023-03-23 at 20:09 -0400, Paul Moore wrote: > > > > > > > On Tue, Mar 14, 2023 at 4:19 AM Roberto Sassu > > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> ... > > Okay, that's fair, but we could still pass the full xattrs array and a > > reference to the current count which could be both read and updated by > > the individual LSMs, right? > > Yes, we could do. > > > The issue is that the separate compaction stage is not something we > > want to have to do if we can avoid it. Maybe we're stuck with it, but > > I'm not yet convinced that we can't make some minor changes to the > > LSMs to avoid the compaction step. > > I liked more the idea that LSMs do what they are most familiar with, > get an offset in a security blob or, in this case, a starting slot in > the new_xattrs array, and write there. > > v3 had the lsm_find_xattr_slot() helper, to get the starting slot, but > somehow I find it less intuitive. > > Ok, if you prefer to avoid the compaction stage, I will rewrite this > patch. My concern is having to look through the xattr array after each LSM has been run and in at least one case having to then do a memcpy() to keep the array packed. There are some cases where there is no way to avoid all that extra work, but here I think we have the LSMs do the Right Thing with respect to packing the xattr array without overly burdening the individual LSMs. Does that make sense? It basically comes down to being smart about our abstractions and both selectively, and carefully, breaking them when there is a reasonable performance gain to be had. -- paul-moore.com
WARNING: multiple messages have this Message-ID (diff)
From: Paul Moore via Ocfs2-devel <ocfs2-devel@oss.oracle.com> To: Roberto Sassu <roberto.sassu@huaweicloud.com> Cc: nicolas.bouchinet@clip-os.org, linux-kernel@vger.kernel.org, keescook@chromium.org, selinux@vger.kernel.org, dmitry.kasatkin@gmail.com, Roberto Sassu <roberto.sassu@huawei.com>, jmorris@namei.org, zohar@linux.ibm.com, reiserfs-devel@vger.kernel.org, linux-security-module@vger.kernel.org, casey@schaufler-ca.com, eparis@parisplace.org, linux-integrity@vger.kernel.org, stephen.smalley.work@gmail.com, ocfs2-devel@oss.oracle.com, serge@hallyn.com Subject: Re: [Ocfs2-devel] [PATCH v8 4/6] security: Allow all LSMs to provide xattrs for inode_init_security hook Date: Tue, 28 Mar 2023 16:19:55 -0400 [thread overview] Message-ID: <CAHC9VhRNWeZtxain_Hi-EfS49Vac8_vg7KRRyV4a9Sq3XPhZsg@mail.gmail.com> (raw) In-Reply-To: <1e08006f9011efa48deaf656c358ca3d438b9768.camel@huaweicloud.com> On Tue, Mar 28, 2023 at 3:47 AM Roberto Sassu <roberto.sassu@huaweicloud.com> wrote: > > On Mon, 2023-03-27 at 17:02 -0400, Paul Moore wrote: > > On Mon, Mar 27, 2023 at 3:30 AM Roberto Sassu > > <roberto.sassu@huaweicloud.com> wrote: > > > On Fri, 2023-03-24 at 17:39 -0400, Paul Moore wrote: > > > > On Fri, Mar 24, 2023 at 9:26 AM Roberto Sassu > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > On Fri, 2023-03-24 at 11:18 +0100, Roberto Sassu wrote: > > > > > > On Thu, 2023-03-23 at 20:09 -0400, Paul Moore wrote: > > > > > > > On Tue, Mar 14, 2023 at 4:19 AM Roberto Sassu > > > > > > > <roberto.sassu@huaweicloud.com> wrote: > > > > > > > > From: Roberto Sassu <roberto.sassu@huawei.com> ... > > Okay, that's fair, but we could still pass the full xattrs array and a > > reference to the current count which could be both read and updated by > > the individual LSMs, right? > > Yes, we could do. > > > The issue is that the separate compaction stage is not something we > > want to have to do if we can avoid it. Maybe we're stuck with it, but > > I'm not yet convinced that we can't make some minor changes to the > > LSMs to avoid the compaction step. > > I liked more the idea that LSMs do what they are most familiar with, > get an offset in a security blob or, in this case, a starting slot in > the new_xattrs array, and write there. > > v3 had the lsm_find_xattr_slot() helper, to get the starting slot, but > somehow I find it less intuitive. > > Ok, if you prefer to avoid the compaction stage, I will rewrite this > patch. My concern is having to look through the xattr array after each LSM has been run and in at least one case having to then do a memcpy() to keep the array packed. There are some cases where there is no way to avoid all that extra work, but here I think we have the LSMs do the Right Thing with respect to packing the xattr array without overly burdening the individual LSMs. Does that make sense? It basically comes down to being smart about our abstractions and both selectively, and carefully, breaking them when there is a reasonable performance gain to be had. -- paul-moore.com _______________________________________________ Ocfs2-devel mailing list Ocfs2-devel@oss.oracle.com https://oss.oracle.com/mailman/listinfo/ocfs2-devel
next prev parent reply other threads:[~2023-03-28 20:20 UTC|newest] Thread overview: 57+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-03-14 8:17 [PATCH v8 0/6] evm: Do HMAC of multiple per LSM xattrs for new inodes Roberto Sassu 2023-03-14 8:17 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-03-14 8:17 ` [Ocfs2-devel] [PATCH v8 1/6] reiserfs: Switch to security_inode_init_security() Roberto Sassu via Ocfs2-devel 2023-03-14 8:17 ` Roberto Sassu 2023-03-23 23:33 ` Paul Moore 2023-03-23 23:33 ` Paul Moore 2023-03-23 23:33 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-14 8:17 ` [Ocfs2-devel] [PATCH v8 2/6] ocfs2: " Roberto Sassu via Ocfs2-devel 2023-03-14 8:17 ` Roberto Sassu 2023-03-17 19:39 ` Mimi Zohar 2023-03-17 19:39 ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel 2023-03-23 23:37 ` Paul Moore 2023-03-23 23:37 ` Paul Moore 2023-03-23 23:37 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-14 8:17 ` [Ocfs2-devel] [PATCH v8 3/6] security: Remove security_old_inode_init_security() Roberto Sassu via Ocfs2-devel 2023-03-14 8:17 ` Roberto Sassu 2023-03-23 23:41 ` Paul Moore 2023-03-23 23:41 ` Paul Moore 2023-03-23 23:41 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-14 8:17 ` [Ocfs2-devel] [PATCH v8 4/6] security: Allow all LSMs to provide xattrs for inode_init_security hook Roberto Sassu via Ocfs2-devel 2023-03-14 8:17 ` Roberto Sassu 2023-03-24 0:09 ` Paul Moore 2023-03-24 0:09 ` Paul Moore 2023-03-24 0:09 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-24 1:01 ` Casey Schaufler 2023-03-24 1:01 ` Casey Schaufler 2023-03-24 1:01 ` [Ocfs2-devel] " Casey Schaufler via Ocfs2-devel 2023-03-24 14:17 ` Paul Moore 2023-03-24 14:17 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-24 10:18 ` Roberto Sassu 2023-03-24 10:18 ` Roberto Sassu 2023-03-24 10:18 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-03-24 13:25 ` Roberto Sassu 2023-03-24 13:25 ` Roberto Sassu 2023-03-24 13:25 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-03-24 21:39 ` Paul Moore 2023-03-24 21:39 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-27 7:29 ` Roberto Sassu 2023-03-27 7:29 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-03-27 21:02 ` Paul Moore 2023-03-27 21:02 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-28 7:46 ` Roberto Sassu 2023-03-28 7:46 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-03-28 20:19 ` Paul Moore [this message] 2023-03-28 20:19 ` Paul Moore via Ocfs2-devel 2023-03-29 7:11 ` Roberto Sassu 2023-03-29 7:11 ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel 2023-03-24 21:19 ` Paul Moore 2023-03-24 21:19 ` [Ocfs2-devel] " Paul Moore via Ocfs2-devel 2023-03-27 7:35 ` Roberto Sassu via Ocfs2-devel 2023-03-27 7:35 ` Roberto Sassu 2023-03-14 8:17 ` [Ocfs2-devel] [PATCH v8 5/6] evm: Align evm_inode_init_security() definition with LSM infrastructure Roberto Sassu via Ocfs2-devel 2023-03-14 8:17 ` Roberto Sassu 2023-03-14 8:17 ` [Ocfs2-devel] [PATCH v8 6/6] evm: Support multiple LSMs providing an xattr Roberto Sassu via Ocfs2-devel 2023-03-14 8:17 ` Roberto Sassu 2023-03-14 8:21 ` [Ocfs2-devel] [PATCH v8 0/6] evm: Do HMAC of multiple per LSM xattrs for new inodes Roberto Sassu via Ocfs2-devel 2023-03-14 8:21 ` Roberto Sassu
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=CAHC9VhRNWeZtxain_Hi-EfS49Vac8_vg7KRRyV4a9Sq3XPhZsg@mail.gmail.com \ --to=paul@paul-moore.com \ --cc=casey@schaufler-ca.com \ --cc=dmitry.kasatkin@gmail.com \ --cc=eparis@parisplace.org \ --cc=jlbec@evilplan.org \ --cc=jmorris@namei.org \ --cc=joseph.qi@linux.alibaba.com \ --cc=keescook@chromium.org \ --cc=linux-integrity@vger.kernel.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-security-module@vger.kernel.org \ --cc=mark@fasheh.com \ --cc=nicolas.bouchinet@clip-os.org \ --cc=ocfs2-devel@oss.oracle.com \ --cc=reiserfs-devel@vger.kernel.org \ --cc=roberto.sassu@huawei.com \ --cc=roberto.sassu@huaweicloud.com \ --cc=selinux@vger.kernel.org \ --cc=serge@hallyn.com \ --cc=stephen.smalley.work@gmail.com \ --cc=zohar@linux.ibm.com \ /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.