linux-hardening - Re: GPM & Emacs broken in Linux 6.7 -- ok to relax check?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Z08QvvfLSWGIDfBD@google.com>
Date: Tue, 3 Dec 2024 15:07:58 +0100
From: "Günther Noack" <gnoack@...gle.com>
To: Jann Horn <jannh@...gle.com>
Cc: Jared Finder <jared@...der.org>, "Hanno Böck" <hanno@...eck.de>, 
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>, Jiri Slaby <jirislaby@...nel.org>, 
	linux-hardening@...r.kernel.org, regressions@...ts.linux.dev, 
	kernel list <linux-kernel@...r.kernel.org>
Subject: Re: GPM & Emacs broken in Linux 6.7 -- ok to relax check?

On Tue, Dec 03, 2024 at 02:53:27PM +0100, Günther Noack wrote:
> 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?)

P.S.: For reference, some more detailed reasoning why I think that that proposal
would be OK:

It would protect at least against the "minittyjack.c" example that was attached
to https://www.openwall.com/lists/oss-security/2023/03/14/3

The trick used there was:

* ioctl() with TIOCLINUX with TIOCL_SETSEL with TIOCL_SELLINE,
  to make a selection (a.k.a. changing the contents of vc_sel)
* ioctl() with TIOCLINUX and TIOCL_PASTESEL to paste the selection.
  (The implementation for that is in selection.c/paste_selection()
  and is just copying from vc_sel.)

So as long as we are protecting the change to vc_sel, that should be OK in my
mind.

—Günther