Linux Hardening
 help / color / mirror / Atom feed
From: "Günther Noack" <gnoack@google.com>
To: Jann Horn <jannh@google.com>
Cc: "Jared Finder" <jared@finder.org>, "Hanno Böck" <hanno@hboeck.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Jiri Slaby" <jirislaby@kernel.org>,
	linux-hardening@vger.kernel.org, regressions@lists.linux.dev,
	"kernel list" <linux-kernel@vger.kernel.org>
Subject: Re: GPM & Emacs broken in Linux 6.7 -- ok to relax check?
Date: Tue, 3 Dec 2024 14:53:27 +0100	[thread overview]
Message-ID: <Z08NV4Z-L0anDxGk@google.com> (raw)
In-Reply-To: <CAG48ez0vg9W=oatvEqxvTSYNUx7htY23LxPrYCiuLZhZQuaGjg@mail.gmail.com>

Hello!

On Fri, Nov 29, 2024 at 08:50:38PM +0100, Jann Horn wrote:
> +regression list, LKML, maintainers, patch authors
> 
> On Fri, Nov 29, 2024 at 8:38 PM Jared Finder <jared@finder.org> wrote:
> > The change to restrict access to TIOCLINUX that was added in Linux 6.7
> > breaks Emacs rendering of the mouse pointer. This change was previous
> > discussed in
> > https://lwn.net/ml/kernel-hardening/20230402160815.74760f87.hanno@hboeck.de/.
> 
> This landed as commit 8d1b43f6a6df ("tty: Restrict access to
> TIOCLINUX' copy-and-paste subcommands").
> 
> #regzbot introduced: 8d1b43f6a6df

Thank you for reporting the bug, and thanks for forwarding, Jann!

> > An associated Emacs bug report, bug #74220, is discussed at
> > https://lists.gnu.org/archive/html/bug-gnu-emacs/2024-11/msg00275.html.
> >
> > I wanted to ask if it made sense for the restriction to not apply to the
> > following three selection modes for TIOCL_SETSEL:
> >
> > TIOCL_SELPOINTER   3 /* show the pointer */
> > TIOCL_SELCLEAR   4 /* clear visibility of selection */
> > TIOCL_SELMOUSEREPORT   16 /* report beginning of selection */
> >
> > On a glance over the selection code, none of these interact with
> > vc_sel.buffer and therefore are unrelated to the exploit linked in the
> > original report. Only SELPOINTER is necessary to be available to fix
> > Emacs bug #74220. I imagine such a change would involve moving the
> > capability check from tioclinux(), case TIOCL_SETSEL to inside
> > vc_do_selection().

We did indeed miss that Emacs is using these IOCTLs directly.

To paraphrase what is happening, so that we are on the same page:

* Emacs includes the GPM header gpm.h and calls Gpm_DrawPointer(x, y, fd).
* Gpm_DrawPointer is implemented as a macro, which hardcodes all IOCTL constants
  (as it is the case in the entire GPM codebase), and it invokes ioctl(2)
  directly from the macro.

The Gpm_DrawPointer also gets called from other packages, including mc (Midnight
Commander), elinks and libt3widget (which supports the Tilde text editor).

https://codesearch.debian.net/search?q=Gpm_DrawPointer&literal=1&perpkg=1

* Midnight Commander and the Tilde text editor display the mouse cursor fine,
  also as a regular user.

* Elinks does not display the mouse cursor at all, independent of whether it is
  being run as root or not.  (Which makes me suspect that it might be an
  independent bug.)

* Emacs does not display the mouse cursor when run as normal user,
  but it works as root.

I can see how the three selection modes TIOCL_SELPOINTER, TIOCL_SELCLEAR and
TIOCL_SELMOUSEREPORT are related - TIOCL_SELPOINTER is the one that we need, but
TIOCL_SELPOINTER and TIOCL_SELCLEAR are the other two which can happen leading
up to that at the top of vc_selection()?

I also believe that what we *actually* want to guard here is the change to
vc_sel, so to propose a (somewhat simple-minded) patch, I guess we could put the
CAP_SYS_ADMIN check in vc_do_selection() right before the place where
vc_sel.start and vc_sel.end are being assigned?

Hanno, you are the original author of this patch and you have done a more
detailed analysis on the TIOCLINUX problems than me -- do you agree that this
weakened check would still be sufficient to protect against the TIOCLINUX
problems?  (Or in other words, if we permitted TIOCL_SELPOINTER, TIOCL_SELCLEAR
and TIOCL_SELMOUSEREPORT for non-CAP_SYS_ADMIN processes, would you still see a
way to misuse that functionality?)

Thanks,
—Günther

  reply	other threads:[~2024-12-03 13:53 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-11-29 19:33 GPM & Emacs broken in Linux 6.7 -- ok to relax check? Jared Finder
2024-11-29 19:50 ` Jann Horn
2024-12-03 13:53   ` Günther Noack [this message]
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
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=Z08NV4Z-L0anDxGk@google.com \
    --to=gnoack@google.com \
    --cc=gregkh@linuxfoundation.org \
    --cc=hanno@hboeck.de \
    --cc=jannh@google.com \
    --cc=jared@finder.org \
    --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