From: Ondrej Mosnacek <omosnace@redhat.com>
To: linux-nfs <linux-nfs@vger.kernel.org>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>,
Linux Security Module list
<linux-security-module@vger.kernel.org>,
SElinux list <selinux@vger.kernel.org>
Subject: Calls to vfs_setlease() from NFSD code cause unnecessary CAP_LEASE security checks
Date: Fri, 2 Feb 2024 16:31:51 +0100 [thread overview]
Message-ID: <CAFqZXNu2V-zV2UHk5006mw8mjURdFmD-74edBeo-7ZX5LJNXag@mail.gmail.com> (raw)
Hello,
In [1] a user reports seeing SELinux denials from NFSD when it writes
into /proc/fs/nfsd/threads with the following kernel backtrace:
=> trace_event_raw_event_selinux_audited
=> avc_audit_post_callback
=> common_lsm_audit
=> slow_avc_audit
=> cred_has_capability.isra.0
=> security_capable
=> capable
=> generic_setlease
=> destroy_unhashed_deleg
=> __destroy_client
=> nfs4_state_shutdown_net
=> nfsd_shutdown_net
=> nfsd_last_thread
=> nfsd_svc
=> write_threads
=> nfsctl_transaction_write
=> vfs_write
=> ksys_write
=> do_syscall_64
=> entry_SYSCALL_64_after_hwframe
It seems to me that the security checks in generic_setlease() should
be skipped (at least) when called through this codepath, since the
userspace process merely writes into /proc/fs/nfsd/threads and it's
just the kernel's internal code that releases the lease as a side
effect. For example, for vfs_write() there is kernel_write(), which
provides a no-security-check equivalent. Should there be something
similar for vfs_setlease() that could be utilized for this purpose?
[1] https://bugzilla.redhat.com/show_bug.cgi?id=2248830
--
Ondrej Mosnacek
Senior Software Engineer, Linux Security - SELinux kernel
Red Hat, Inc.
next reply other threads:[~2024-02-02 15:32 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-02 15:31 Ondrej Mosnacek [this message]
2024-02-02 16:05 ` Calls to vfs_setlease() from NFSD code cause unnecessary CAP_LEASE security checks Jeff Layton
2024-02-02 16:31 ` Ondrej Mosnacek
2024-02-08 14:28 ` Ondrej Mosnacek
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=CAFqZXNu2V-zV2UHk5006mw8mjURdFmD-74edBeo-7ZX5LJNXag@mail.gmail.com \
--to=omosnace@redhat.com \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-nfs@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=selinux@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 read-only IMAP folder(s) and NNTP newsgroup(s).