From: Greg KH <gregkh@linuxfoundation.org>
To: "Hanno Böck" <hanno@hboeck.de>
Cc: kernel-hardening@lists.openwall.com
Subject: Re: [PATCH] Restrict access to TIOCLINUX
Date: Sun, 2 Apr 2023 16:55:01 +0200 [thread overview]
Message-ID: <2023040232-untainted-duration-daf6@gregkh> (raw)
In-Reply-To: <20230402160815.74760f87.hanno@hboeck.de>
On Sun, Apr 02, 2023 at 04:08:15PM +0200, Hanno Böck wrote:
> Hi,
>
> I'm sending this here before I'll try to send it to lkml and the
> respective maintainers to get some feedback first.
>
> The TIOCLINUX functionality in the kernel can be abused for privilege
> escalation, similar to TIOCSTI. I considered a few options how to fix
> this, and this is what I came up with.
>
>
> Restrict access to TIOCLINUX
>
> TIOCLINUX can be used for privilege escalation on virtual terminals when
> code is executed via tools like su/sudo.
> By abusing the selection features a lower-privileged application can
> write content to the console, select and copy/paste that content and
> thereby executing code on the privileged account. See also the poc here:
> https://www.openwall.com/lists/oss-security/2023/03/14/3
>
> Selection is usually used by tools like gpm that provide mouse features
> on the virtual console. gpm already runs as root (due to earlier
> changes that restrict access to a user on the current tty), therefore
> it will still work with this change.
>
> The security problem mitigated is similar to the security risks caused
> by TIOCSTI, which, since kernel 6.2, can be disabled with
> CONFIG_LEGACY_TIOCSTI=n.
>
> Signed-off-by: Hanno Böck <hanno@hboeck.de>
> ---
> drivers/tty/vt/vt.c | 6 ++++++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/tty/vt/vt.c b/drivers/tty/vt/vt.c
> index 3c2ea9c098f7..3671173109b8 100644
> --- a/drivers/tty/vt/vt.c
> +++ b/drivers/tty/vt/vt.c
> @@ -3146,10 +3146,14 @@ int tioclinux(struct tty_struct *tty, unsigned
> long arg) switch (type)
> {
> case TIOCL_SETSEL:
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
You just now broke any normal user programs that required this (or the
other ioctls), and so you are going to have to force them to be run with
CAP_SYS_ADMIN permissions? That feels like you are going backwards in
security, not forwards.
And you didn't change anything for programs like gpm that already had
root permission (and shouldn't that permission be dropped anyway?)
thanks,
greg k-h
next prev parent reply other threads:[~2023-04-02 14:55 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-02 14:08 [PATCH] Restrict access to TIOCLINUX Hanno Böck
2023-04-02 14:55 ` Greg KH [this message]
2023-04-02 17:16 ` Hanno Böck
2023-04-02 17:23 ` Greg KH
2023-04-02 17:33 ` Hanno Böck
2023-04-02 17:44 ` Greg KH
2023-04-04 21:54 ` Jordan Glover
2023-08-18 16:10 ` Günther Noack
2023-08-22 12:07 ` Greg KH
2023-08-22 12:51 ` Boris Lukashev
2023-08-22 13:34 ` Greg KH
2023-08-22 18:22 ` Günther Noack
2023-08-23 14:36 ` Greg KH
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=2023040232-untainted-duration-daf6@gregkh \
--to=gregkh@linuxfoundation.org \
--cc=hanno@hboeck.de \
--cc=kernel-hardening@lists.openwall.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.