From: "Mickaël Salaün" <mic@digikod.net>
To: Paul Moore <paul@paul-moore.com>
Cc: linux-security-module@vger.kernel.org, selinux@vger.kernel.org,
"Mimi Zohar" <zohar@linux.ibm.com>,
"Roberto Sassu" <roberto.sassu@huawei.com>,
"Günther Noack" <gnoack@google.com>
Subject: Re: [RFC PATCH] lsm: add the inode_free_security_rcu() LSM implementation hook
Date: Mon, 15 Jul 2024 15:34:53 +0200 [thread overview]
Message-ID: <20240715.aeyaiRa0quie@digikod.net> (raw)
In-Reply-To: <CAHC9VhT=t0Y55i7fJx-HHg3sGCnsSKn=nMCiRiXskdBzs1JVvQ@mail.gmail.com>
On Wed, Jul 10, 2024 at 12:24:31PM -0400, Paul Moore wrote:
> On Wed, Jul 10, 2024 at 8:02 AM Mickaël Salaün <mic@digikod.net> wrote:
> > On Tue, Jul 09, 2024 at 10:47:45PM -0400, Paul Moore wrote:
> > > On Tue, Jul 9, 2024 at 10:40 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >
> > > > The LSM framework has an existing inode_free_security() hook which
> > > > is used by LSMs that manage state associated with an inode, but
> > > > due to the use of RCU to protect the inode, special care must be
> > > > taken to ensure that the LSMs do not fully release the inode state
> > > > until it is safe from a RCU perspective.
> > > >
> > > > This patch implements a new inode_free_security_rcu() implementation
> > > > hook which is called when it is safe to free the LSM's internal inode
> > > > state. Unfortunately, this new hook does not have access to the inode
> > > > itself as it may already be released, so the existing
> > > > inode_free_security() hook is retained for those LSMs which require
> > > > access to the inode.
> > > >
> > > > Signed-off-by: Paul Moore <paul@paul-moore.com>
> > > > ---
> > > > include/linux/lsm_hook_defs.h | 1 +
> > > > security/integrity/ima/ima.h | 2 +-
> > > > security/integrity/ima/ima_iint.c | 20 ++++++++------------
> > > > security/integrity/ima/ima_main.c | 2 +-
> > > > security/landlock/fs.c | 9 ++++++---
> > > > security/security.c | 26 +++++++++++++-------------
> > > > 6 files changed, 30 insertions(+), 30 deletions(-)
> > >
> > > FYI, this has only received "light" testing, and even that is fairly
> > > generous. I booted up a system with IMA set to measure the TCB and
> > > ran through the audit and SELinux test suites; IMA seemed to be
> > > working just fine but I didn't poke at it too hard. I didn't have an
> > > explicit Landlock test handy, but I'm hoping that the Landlock
> > > enablement on a modern Rawhide system hit it a little :)
> >
> > If you want to test Landlock, you can do so like this:
> >
> > cd tools/testing/selftests/landlock
> > make -C ../../../.. headers_install
> > make
> > for f in *_test; ./$f; done
>
> Looks okay?
>
> % for f in *_test; do ./$f; done | grep "^# Totals"
> # Totals: pass:7 fail:0 xfail:0 xpass:0 skip:0 error:0
> # SKIP overlayfs is not supported (setup)
> # SKIP overlayfs is not supported (setup)
> # SKIP this filesystem is not supported (setup)
> # SKIP this filesystem is not supported (setup)
> # SKIP this filesystem is not supported (setup)
> # SKIP this filesystem is not supported (setup)
> # SKIP this filesystem is not supported (setup)
> # Totals: pass:117 fail:0 xfail:0 xpass:0 skip:7 error:0
> # Totals: pass:84 fail:0 xfail:0 xpass:0 skip:0 error:0
> # Totals: pass:8 fail:0 xfail:0 xpass:0 skip:0 error:0
It should be enough, thanks. FYI, the minimal configuration required to
run all tests (except hostfs) is listed in
tools/testing/selftests/landlock/config
next prev parent reply other threads:[~2024-07-15 13:42 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-07-10 2:40 [RFC PATCH] lsm: add the inode_free_security_rcu() LSM implementation hook Paul Moore
2024-07-10 2:47 ` Paul Moore
2024-07-10 12:02 ` Mickaël Salaün
2024-07-10 16:24 ` Paul Moore
2024-07-15 13:34 ` Mickaël Salaün [this message]
2024-07-15 20:51 ` Paul Moore
2024-07-10 10:40 ` Mickaël Salaün
2024-07-10 16:20 ` Paul Moore
2024-07-10 16:41 ` Casey Schaufler
2024-07-10 17:48 ` Paul Moore
2024-07-15 13:35 ` Mickaël Salaün
2024-07-15 21:23 ` Paul Moore
2024-07-22 12:29 ` Matus Jokay
2024-07-22 19:46 ` Paul Moore
2024-07-23 3:34 ` Dave Chinner
2024-07-23 10:01 ` Matus Jokay
2024-07-23 15:19 ` Christian Brauner
2024-07-23 20:03 ` Paul Moore
2024-07-23 23:17 ` Dave Chinner
2024-07-25 10:52 ` Christian Brauner
2024-07-23 9:27 ` Matus Jokay
2024-07-23 19:48 ` Paul Moore
2024-07-24 10:20 ` Matus Jokay
2024-07-10 21:01 ` Roberto Sassu
2024-07-10 21:24 ` Paul Moore
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=20240715.aeyaiRa0quie@digikod.net \
--to=mic@digikod.net \
--cc=gnoack@google.com \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=roberto.sassu@huawei.com \
--cc=selinux@vger.kernel.org \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox