From: Al Viro <viro@zeniv.linux.org.uk>
To: linux-security-module@vger.kernel.org
Cc: linux-integrity@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: [PATCHES][CFR][CFT] securityfs cleanups and fixes
Date: Thu, 12 Jun 2025 04:09:51 +0100 [thread overview]
Message-ID: <20250612030951.GC1647736@ZenIV> (raw)
Resurrected and somewhat fixed series of securityfs
cleanups and fixes:
* one extra reference is enough to pin a dentry down; no need
for two. Switch to regular scheme, similar to shmem, debugfs,
etc. - that fixes securityfs_recursive_remove() dentry leak,
among other things.
* we need to have the filesystem pinned to prevent the contents
disappearing; what we do not need is pinning it for each file.
Doing that only for files and directories in the root is enough.
* the previous two changes allow to get rid of the racy kludges
in efi_secret_unlink(), where we can use simple_unlink() instead
of securityfs_remove(). Which does not require unlocking and
relocking the parent, with all deadlocks that invites.
* Make securityfs_remove() take the entire subtree out, turning
securityfs_recursive_remove() into its alias. Makes a lot more
sense for callers and fixes a mount leak, while we are at it.
* Making securityfs_remove() remove the entire subtree allows for
much simpler life in most of the users - efi_secret, ima_fs,
evm, ipe, tmp get cleaner. I hadn't touched apparmor use of
securityfs, but I suspect that it would be useful there as well.
Branch (6.16-rc1-based) lives in
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs.git #work.securityfs
Individual patches in followups.
Help with testing and review would be very welcome.
Shortlog:
securityfs: don't pin dentries twice, once is enough...
securityfs: pin filesystem only for objects directly in root
fix locking in efi_secret_unlink()
make securityfs_remove() remove the entire subtree
efi_secret: clean securityfs use up
ima_fs: don't bother with removal of files in directory we'll be removing
ima_fs: get rid of lookup-by-dentry stuff
evm_secfs: clear securityfs interactions
ipe: don't bother with removal of files in directory we'll be removing
tpm: don't bother with removal of files in directory we'll be removing
Diffstat:
drivers/char/tpm/eventlog/common.c | 46 +++-------
drivers/virt/coco/efi_secret/efi_secret.c | 47 ++--------
include/linux/security.h | 3 +-
include/linux/tpm.h | 2 +-
security/inode.c | 62 +++++---------
security/integrity/evm/evm_secfs.c | 15 ++--
security/integrity/ima/ima_fs.c | 137 +++++++-----------------------
security/ipe/fs.c | 32 +++----
security/ipe/policy_fs.c | 4 +-
9 files changed, 97 insertions(+), 251 deletions(-)
next reply other threads:[~2025-06-12 3:09 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-06-12 3:09 Al Viro [this message]
2025-06-12 3:11 ` [PATCH 01/10] securityfs: don't pin dentries twice, once is enough Al Viro
2025-06-12 3:11 ` [PATCH 02/10] securityfs: pin filesystem only for objects directly in root Al Viro
2025-06-12 3:11 ` [PATCH 03/10] fix locking in efi_secret_unlink() Al Viro
2025-06-12 3:11 ` [PATCH 04/10] make securityfs_remove() remove the entire subtree Al Viro
2025-06-12 3:11 ` [PATCH 05/10] efi_secret: clean securityfs use up Al Viro
2025-06-12 3:11 ` [PATCH 06/10] ima_fs: don't bother with removal of files in directory we'll be removing Al Viro
2025-06-17 18:42 ` Mimi Zohar
2025-06-12 3:11 ` [PATCH 07/10] ima_fs: get rid of lookup-by-dentry stuff Al Viro
2025-06-17 18:42 ` Mimi Zohar
2025-06-12 3:11 ` [PATCH 08/10] evm_secfs: clear securityfs interactions Al Viro
2025-06-17 19:49 ` Mimi Zohar
2025-06-12 3:11 ` [PATCH 09/10] ipe: don't bother with removal of files in directory we'll be removing Al Viro
2025-06-12 17:43 ` Fan Wu
2025-06-24 23:49 ` Fan Wu
2025-06-12 3:11 ` [PATCH 10/10] tpm: " Al Viro
2025-06-25 1:47 ` [PATCHES][CFR][CFT] securityfs cleanups and fixes Al Viro
2025-06-25 2:07 ` 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=20250612030951.GC1647736@ZenIV \
--to=viro@zeniv.linux.org.uk \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-security-module@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: 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;
as well as URLs for NNTP newsgroup(s).