From: "Günther Noack" <gnoack@google.com>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: "Jann Horn" <jannh@google.com>, "Hanno Böck" <hanno@hboeck.de>,
"Jiri Slaby" <jirislaby@kernel.org>,
linux-hardening@vger.kernel.org, regressions@lists.linux.dev,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN
Date: Mon, 16 Dec 2024 16:42:50 +0100 [thread overview]
Message-ID: <Z2BKetPygDM36X-X@google.com> (raw)
In-Reply-To: <2024121653-unblessed-mummified-c630@gregkh>
Hello!
On Mon, Dec 16, 2024 at 04:17:15PM +0100, Greg Kroah-Hartman wrote:
> On Mon, Dec 16, 2024 at 03:07:23PM +0000, Günther Noack wrote:
> > With this, processes without CAP_SYS_ADMIN are able to use TIOCLINUX with
> > subcode TIOCL_SETSEL, in the selection modes TIOCL_SETPOINTER,
> > TIOCL_SELCLEAR and TIOCL_SELMOUSEREPORT.
> >
> > TIOCL_SETSEL was previously changed to require CAP_SYS_ADMIN, as this IOCTL
> > let callers change the selection buffer and could be used to simulate
> > keypresses. These three TIOCL_SETSEL selection modes, however, are safe to
> > use, as they do not modify the selection buffer.
> >
> > This fixes a mouse support regression that affected Emacs (invisible mouse
> > cursor).
> >
> > Link: https://lore.kernel.org/r/ee3ec63269b43b34e1c90dd8c9743bf8@finder.org
> > Fixes: 8d1b43f6a6df ("tty: Restrict access to TIOCLINUX' copy-and-paste subcommands")
> > Signed-off-by: Günther Noack <gnoack@google.com>
> > ---
> > drivers/tty/vt/selection.c | 14 ++++++++++++++
> > drivers/tty/vt/vt.c | 3 +--
> > 2 files changed, 15 insertions(+), 2 deletions(-)
> >
> > diff --git a/drivers/tty/vt/selection.c b/drivers/tty/vt/selection.c
> > index 564341f1a74f..0bd6544e30a6 100644
> > --- a/drivers/tty/vt/selection.c
> > +++ b/drivers/tty/vt/selection.c
> > @@ -192,6 +192,20 @@ int set_selection_user(const struct tiocl_selection __user *sel,
> > if (copy_from_user(&v, sel, sizeof(*sel)))
> > return -EFAULT;
> >
> > + /*
> > + * TIOCL_SELCLEAR, TIOCL_SELPOINTER and TIOCL_SELMOUSEREPORT are OK to
> > + * use without CAP_SYS_ADMIN as they do not modify the selection.
> > + */
> > + switch (v.sel_mode) {
> > + case TIOCL_SELCLEAR:
> > + case TIOCL_SELPOINTER:
> > + case TIOCL_SELMOUSEREPORT:
> > + break;
> > + default:
> > + if (!capable(CAP_SYS_ADMIN))
> > + return -EPERM;
> > + }
>
> Shouldn't you check this _before_ doing the copy_from_user() to emulate
> the previous logic properly?
You are right, I believe this can technically return a different error code.
There is a data dependency between the two though - the capability check should
only happen for certain values of v.sel_mode, and v is only populated by
copy_from_user().
As far as I can tell, this only makes a difference in scenarios where both
copy_from_user() and the capability check would fail.
Do you think we have to emulate it down to this level of detail?
As background, we have only introduced the CAP_SYS_ADMIN check recently in
8d1b43f6a6df ("tty: Restrict access to TIOCLINUX' copy-and-paste subcommands")
The patch landed in Linux 6.7 and was discussed in
https://lore.kernel.org/all/20230828164117.3608812-1-gnoack@google.com/.
I suspect that existing callers of the TIOCL_SETSEL IOCTL are probably all
written at a time before the capability check existed. ((a) These IOCTLs are
used for the console mouse support, and (b) these "modes" for the TIOCL_SETSEL
subcode for the TIOCLINUX IOCTL are not documented in the man page either.)
>
> > +
> > return set_selection_kernel(&v, tty);
> > }
> >
> > diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> > index 96842ce817af..ed65b3b80fbd 100644
> > --- a/drivers/tty/vt/vt.c
> > +++ b/drivers/tty/vt/vt.c
> > @@ -3345,8 +3345,7 @@ int tioclinux(struct tty_struct *tty, unsigned long arg)
> >
> > switch (type) {
> > case TIOCL_SETSEL:
> > - if (!capable(CAP_SYS_ADMIN))
> > - return -EPERM;
> > + /* CAP_SYS_ADMIN check happens in set_selection_user(). */
>
> No need to mention this here, it's obvious in the function itself.
OK, thanks. I will remove it in the next version.
—Günther
next prev parent reply other threads:[~2024-12-16 15:42 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <ee3ec63269b43b34e1c90dd8c9743bf8@finder.org>
2024-11-29 19:50 ` GPM & Emacs broken in Linux 6.7 -- ok to relax check? Jann Horn
2024-12-03 13:53 ` Günther Noack
2024-12-03 14:07 ` Günther Noack
2024-12-14 5:13 ` Jared Finder
2024-12-14 7:47 ` Greg Kroah-Hartman
2024-12-16 15:07 ` [PATCH] tty: Permit some TIOCL_SETSEL modes without CAP_SYS_ADMIN Günther Noack
2024-12-16 15:14 ` Greg Kroah-Hartman
2024-12-16 15:17 ` Greg Kroah-Hartman
2024-12-16 15:42 ` Günther Noack [this message]
2024-12-21 11:06 ` Günther Noack
2024-12-21 11:10 ` [PATCH v2] " Günther Noack
2024-12-22 8:37 ` Greg Kroah-Hartman
2025-01-10 14:21 ` Günther Noack
2025-01-10 16:50 ` Kees Cook
2025-02-08 15:18 ` Jared Finder
2025-02-08 15:28 ` Greg KH
2025-02-08 16:03 ` Jared Finder
2025-02-09 6:49 ` Greg KH
2025-02-21 0:10 ` Günther Noack
2025-02-22 21:07 ` Jared Finder
2025-01-12 13:14 ` Greg Kroah-Hartman
2024-12-17 9:09 ` [PATCH] " Günther Noack
2024-12-17 8:47 ` GPM & Emacs broken in Linux 6.7 -- ok to relax check? Hanno Böck
2024-12-17 8:49 ` Greg Kroah-Hartman
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=Z2BKetPygDM36X-X@google.com \
--to=gnoack@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=hanno@hboeck.de \
--cc=jannh@google.com \
--cc=jirislaby@kernel.org \
--cc=linux-hardening@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=regressions@lists.linux.dev \
/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).