All of lore.kernel.org
 help / color / mirror / Atom feed
From: Mimi Zohar via Ocfs2-devel <ocfs2-devel@oss.oracle.com>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>,
	mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com,
	dmitry.kasatkin@gmail.com, paul@paul-moore.com,
	jmorris@namei.org, serge@hallyn.com,
	stephen.smalley.work@gmail.com, eparis@parisplace.org,
	casey@schaufler-ca.com
Cc: nicolas.bouchinet@clip-os.org, keescook@chromium.org,
	selinux@vger.kernel.org, Roberto Sassu <roberto.sassu@huawei.com>,
	reiserfs-devel@vger.kernel.org, linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	linux-integrity@vger.kernel.org, ocfs2-devel@oss.oracle.com
Subject: Re: [Ocfs2-devel] [PATCH v5 0/6] evm: Prepare for moving to the LSM infrastructure
Date: Wed, 23 Nov 2022 08:06:38 -0500	[thread overview]
Message-ID: <bddfe0f41b05dd8efd6991487ff2525a8503dd84.camel@linux.ibm.com> (raw)
In-Reply-To: <22f47b9d2cade322f9037133b0940640423f9590.camel@huaweicloud.com>

On Wed, 2022-11-23 at 13:44 +0100, Roberto Sassu wrote:
> On Wed, 2022-11-23 at 07:28 -0500, Mimi Zohar wrote:
> > Hi Roberto,
> > 
> > On Wed, 2022-11-23 at 10:51 +0100, Roberto Sassu wrote:
> > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > 
> > > One of the challenges that must be tackled to move IMA and EVM to the LSM
> > > infrastructure is to ensure that EVM is capable to correctly handle
> > > multiple stacked LSMs providing an xattr at file creation. At the moment,
> > > there are few issues that would prevent a correct integration. This patch
> > > set aims at solving them.
> > 
> > Let's take a step back and understand the purpose of this patch set. 
> > Regardless of whether IMA and EVM are moved to the "LSM
> > infrastructure", EVM needs to support per LSM xattrs.  A side affect is
> > the removal of the security_old_inode_init_security hook.  This patch
> > set cover letter and patch descriptions should be limited to EVM
> > support for per LSM (multiple) xattrs.  The motivation, concerns, and
> > problems of making IMA and EVM LSMs will be documented in the patch set
> > that actual makes them LSMs.  Please remove all references to "move IMA
> > and EVM to the LSM infrastructure".
> 
> Hi Mimi
> 
> ok, will do.
> 
> > When EVM was upstreamed, there were filesystem limitations on the
> > number and size of the extended attributes.  In addition there were
> > performance concerns, which resulted in staging the LSM, IMA and EVM
> > xattrs, before calling initxattrs to write them at the same time.  With
> > this patch set, not only are per LSM xattrs supported, but multiple per
> > LSM xattrs are supported as well.  Have the size limitation concerns
> > been addressed by the different filesystems?   If not, then at minimum
> > this patch set needs to at least mention it and the possible
> > ramifications.
> 
> With your patch, 9d8f13ba3f483 ("security: new
> security_inode_init_security API adds function callback") you made it
> possible to set multiple xattrs at inode creation time.

True, and even then there were concerns.

> This patch set pushes further to the limits, as there could be more
> xattrs to be added to the inode. I will mention that.

Thanks

> If there are too many xattrs, I guess the only solution would be to use
> less LSMs, or a different filesystem. The per filesystem limit could be
> increased separately case by case.

Agreed, but unless it is documented somewhere, nobody but us will know
there is a potential problem.  At least document it here in the cover
letter, which we'll include in the merge message.

FYI, the xattr.7 man page contains a section "Filesystem differences".

-- 
thanks,

Mimi


_______________________________________________
Ocfs2-devel mailing list
Ocfs2-devel@oss.oracle.com
https://oss.oracle.com/mailman/listinfo/ocfs2-devel

WARNING: multiple messages have this Message-ID (diff)
From: Mimi Zohar <zohar@linux.ibm.com>
To: Roberto Sassu <roberto.sassu@huaweicloud.com>,
	mark@fasheh.com, jlbec@evilplan.org, joseph.qi@linux.alibaba.com,
	dmitry.kasatkin@gmail.com, paul@paul-moore.com,
	jmorris@namei.org, serge@hallyn.com,
	stephen.smalley.work@gmail.com, eparis@parisplace.org,
	casey@schaufler-ca.com
Cc: 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 v5 0/6] evm: Prepare for moving to the LSM infrastructure
Date: Wed, 23 Nov 2022 08:06:38 -0500	[thread overview]
Message-ID: <bddfe0f41b05dd8efd6991487ff2525a8503dd84.camel@linux.ibm.com> (raw)
In-Reply-To: <22f47b9d2cade322f9037133b0940640423f9590.camel@huaweicloud.com>

On Wed, 2022-11-23 at 13:44 +0100, Roberto Sassu wrote:
> On Wed, 2022-11-23 at 07:28 -0500, Mimi Zohar wrote:
> > Hi Roberto,
> > 
> > On Wed, 2022-11-23 at 10:51 +0100, Roberto Sassu wrote:
> > > From: Roberto Sassu <roberto.sassu@huawei.com>
> > > 
> > > One of the challenges that must be tackled to move IMA and EVM to the LSM
> > > infrastructure is to ensure that EVM is capable to correctly handle
> > > multiple stacked LSMs providing an xattr at file creation. At the moment,
> > > there are few issues that would prevent a correct integration. This patch
> > > set aims at solving them.
> > 
> > Let's take a step back and understand the purpose of this patch set. 
> > Regardless of whether IMA and EVM are moved to the "LSM
> > infrastructure", EVM needs to support per LSM xattrs.  A side affect is
> > the removal of the security_old_inode_init_security hook.  This patch
> > set cover letter and patch descriptions should be limited to EVM
> > support for per LSM (multiple) xattrs.  The motivation, concerns, and
> > problems of making IMA and EVM LSMs will be documented in the patch set
> > that actual makes them LSMs.  Please remove all references to "move IMA
> > and EVM to the LSM infrastructure".
> 
> Hi Mimi
> 
> ok, will do.
> 
> > When EVM was upstreamed, there were filesystem limitations on the
> > number and size of the extended attributes.  In addition there were
> > performance concerns, which resulted in staging the LSM, IMA and EVM
> > xattrs, before calling initxattrs to write them at the same time.  With
> > this patch set, not only are per LSM xattrs supported, but multiple per
> > LSM xattrs are supported as well.  Have the size limitation concerns
> > been addressed by the different filesystems?   If not, then at minimum
> > this patch set needs to at least mention it and the possible
> > ramifications.
> 
> With your patch, 9d8f13ba3f483 ("security: new
> security_inode_init_security API adds function callback") you made it
> possible to set multiple xattrs at inode creation time.

True, and even then there were concerns.

> This patch set pushes further to the limits, as there could be more
> xattrs to be added to the inode. I will mention that.

Thanks

> If there are too many xattrs, I guess the only solution would be to use
> less LSMs, or a different filesystem. The per filesystem limit could be
> increased separately case by case.

Agreed, but unless it is documented somewhere, nobody but us will know
there is a potential problem.  At least document it here in the cover
letter, which we'll include in the merge message.

FYI, the xattr.7 man page contains a section "Filesystem differences".

-- 
thanks,

Mimi


  reply	other threads:[~2022-11-23 13:07 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-23  9:51 [Ocfs2-devel] [PATCH v5 0/6] evm: Prepare for moving to the LSM infrastructure Roberto Sassu via Ocfs2-devel
2022-11-23  9:51 ` Roberto Sassu
2022-11-23  9:51 ` [Ocfs2-devel] [PATCH v5 1/6] reiserfs: Switch to security_inode_init_security() Roberto Sassu via Ocfs2-devel
2022-11-23  9:51   ` Roberto Sassu
2022-11-23 13:12   ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel
2022-11-23 13:12     ` Mimi Zohar
2022-11-23  9:51 ` [Ocfs2-devel] [PATCH v5 2/6] ocfs2: " Roberto Sassu via Ocfs2-devel
2022-11-23  9:51   ` Roberto Sassu
2022-11-23 17:46   ` Mimi Zohar
2022-11-23 17:46     ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel
2022-11-24  8:11     ` Roberto Sassu via Ocfs2-devel
2022-11-24  8:11       ` Roberto Sassu
2022-11-29 13:14       ` [Ocfs2-devel] " Mimi Zohar via Ocfs2-devel
2022-11-29 13:14         ` Mimi Zohar
2022-12-13  8:05         ` Roberto Sassu
2022-12-13  8:05           ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel
2022-11-23  9:51 ` [Ocfs2-devel] [PATCH v5 3/6] security: Remove security_old_inode_init_security() Roberto Sassu via Ocfs2-devel
2022-11-23  9:51   ` Roberto Sassu
2022-11-23  9:52 ` [Ocfs2-devel] [PATCH v5 4/6] security: Allow all LSMs to provide xattrs for inode_init_security hook Roberto Sassu via Ocfs2-devel
2022-11-23  9:52   ` Roberto Sassu
2022-11-23  9:52 ` [Ocfs2-devel] [PATCH v5 5/6] evm: Align evm_inode_init_security() definition with LSM infrastructure Roberto Sassu via Ocfs2-devel
2022-11-23  9:52   ` Roberto Sassu
2022-11-23  9:52 ` [Ocfs2-devel] [PATCH v5 6/6] evm: Support multiple LSMs providing an xattr Roberto Sassu via Ocfs2-devel
2022-11-23  9:52   ` Roberto Sassu
2022-11-23 12:28 ` [Ocfs2-devel] [PATCH v5 0/6] evm: Prepare for moving to the LSM infrastructure Mimi Zohar via Ocfs2-devel
2022-11-23 12:28   ` Mimi Zohar
2022-11-23 12:44   ` [Ocfs2-devel] " Roberto Sassu via Ocfs2-devel
2022-11-23 12:44     ` Roberto Sassu
2022-11-23 13:06     ` Mimi Zohar via Ocfs2-devel [this message]
2022-11-23 13:06       ` Mimi Zohar

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=bddfe0f41b05dd8efd6991487ff2525a8503dd84.camel@linux.ibm.com \
    --to=ocfs2-devel@oss.oracle.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=paul@paul-moore.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: link
Be 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.