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:35 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 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.