From: Greg KH <gregkh@linuxfoundation.org>
To: Eric Biggers <ebiggers@kernel.org>
Cc: stable@vger.kernel.org, linux-security-module@vger.kernel.org,
selinux@vger.kernel.org, linux-fsdevel@vger.kernel.org,
Alfred Piccioni <alpic@google.com>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <stephen.smalley.work@gmail.com>
Subject: Re: [PATCH 5.4,4.19] lsm: new security_file_ioctl_compat() hook
Date: Wed, 21 Feb 2024 11:52:00 +0100 [thread overview]
Message-ID: <2024022148-gallows-ravine-92bd@gregkh> (raw)
In-Reply-To: <20240206012953.114308-1-ebiggers@kernel.org>
On Mon, Feb 05, 2024 at 05:29:53PM -0800, Eric Biggers wrote:
> From: Alfred Piccioni <alpic@google.com>
>
> commit f1bb47a31dff6d4b34fb14e99850860ee74bb003 upstream.
> [Please apply to 5.4-stable and 4.19-stable. The upstream commit failed
> to apply to these kernels. This patch resolves the conflicts.]
>
> Some ioctl commands do not require ioctl permission, but are routed to
> other permissions such as FILE_GETATTR or FILE_SETATTR. This routing is
> done by comparing the ioctl cmd to a set of 64-bit flags (FS_IOC_*).
>
> However, if a 32-bit process is running on a 64-bit kernel, it emits
> 32-bit flags (FS_IOC32_*) for certain ioctl operations. These flags are
> being checked erroneously, which leads to these ioctl operations being
> routed to the ioctl permission, rather than the correct file
> permissions.
>
> This was also noted in a RED-PEN finding from a while back -
> "/* RED-PEN how should LSM module know it's handling 32bit? */".
>
> This patch introduces a new hook, security_file_ioctl_compat(), that is
> called from the compat ioctl syscall. All current LSMs have been changed
> to support this hook.
>
> Reviewing the three places where we are currently using
> security_file_ioctl(), it appears that only SELinux needs a dedicated
> compat change; TOMOYO and SMACK appear to be functional without any
> change.
>
> Cc: stable@vger.kernel.org
> Fixes: 0b24dcb7f2f7 ("Revert "selinux: simplify ioctl checking"")
> Signed-off-by: Alfred Piccioni <alpic@google.com>
> Reviewed-by: Stephen Smalley <stephen.smalley.work@gmail.com>
> [PM: subject tweak, line length fixes, and alignment corrections]
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> Signed-off-by: Eric Biggers <ebiggers@google.com>
Now queued up, thanks.
greg k-h
prev parent reply other threads:[~2024-02-21 10:52 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-02-06 1:29 [PATCH 5.4,4.19] lsm: new security_file_ioctl_compat() hook Eric Biggers
2024-02-21 10:52 ` Greg KH [this message]
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=2024022148-gallows-ravine-92bd@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=alpic@google.com \
--cc=ebiggers@kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=selinux@vger.kernel.org \
--cc=stable@vger.kernel.org \
--cc=stephen.smalley.work@gmail.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.