[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <ZOT8zL8tXqy41XmM@google.com>
Date: Tue, 22 Aug 2023 20:22:04 +0200
From: "Günther Noack" <gnoack@...gle.com>
To: Greg KH <gregkh@...uxfoundation.org>
Cc: "Hanno Böck" <hanno@...eck.de>, kernel-hardening@...ts.openwall.com,
Kees Cook <keescook@...omium.org>, Jiri Slaby <jirislaby@...nel.org>,
Geert Uytterhoeven <geert@...ux-m68k.org>, Paul Moore <paul@...l-moore.com>,
Samuel Thibault <samuel.thibault@...-lyon.org>, David Laight <David.Laight@...lab.com>,
Simon Brand <simon.brand@...tadigitale.de>, Dave Mielke <Dave@...lke.cc>,
"Mickaël Salaün" <mic@...ikod.net>, KP Singh <kpsingh@...gle.com>
Subject: Re: [PATCH] Restrict access to TIOCLINUX
Hi!
Thanks for re-considering this patch set!
On Tue, Aug 22, 2023 at 02:07:24PM +0200, Greg KH wrote:
> On Fri, Aug 18, 2023 at 06:10:18PM +0200, Günther Noack wrote:
> > The only program that I am aware of which uses cut&paste on the console is gpm.
> > My web searches for these subcode names have only surfaced Linux header files
> > and discussions about their security problems.
>
> Is gpm running with the needed permissions already?
Yes, this should work.
GPM runs as root with the CAP_SYS_ADMIN capability (and many others).
> > We have this problem with the Landlock LSM as well, with both TIOCSTI and these
> > TIOCLINUX subcodes.
> >
> > Here is an example scenario:
> >
> > * User runs a vulnerable version of the "ping" command from the console.
>
> Don't do that :)
>
> > * The "ping" command is a hardened version which puts itself into a Landlock
> > sandbox, but it still has the TTY FD through stdout.
> >
> > * Ping gets buffer-overflow-exploited by an attacker through ping responses.
>
> You allowed a root-permissioned program to accept unsolicted network
> code, why is it the kernel's issue here?
I did not mean to imply that ping runs as root due to the setuid flag. In this
scenario, ping runs as a normal user with only a few additional networking
capabilities (as I believe it is common on most distributions now?).
Also, as Landlock is a sandboxing feature, it makes sense to assume from that
perspective that the confined process is already hostile.
So the privilege boundary that the example is about is not that the ping process
was successfully attacked (that is a problem too), but it is that the
now-hostile ping process can escape the sandbox through the TTY file descriptor.
It is the *shell* which has more privileges for accessing *files* than the ping
process has. This is because the ping process has self-confined itself with a
Landlock sandbox before it was attacked, and therefore ping itself only has very
limited access to files.
ping is indeed a bit unusual because of the special capabilities it needs -- the
same example would also apply to netcat, or any other Unix utility which
commonly gets invoked from the command line, which processes untrusted input,
and which should sandbox itself.
> > * The attacker can't directly access the file system, but the attacker can
> > escape the sandbox by controlling the surrounding (non-sandboxed) shell on its
> > terminal through TIOCLINUX.
> >
> > The ping example is not completely made up -- FreeBSD had such a vulnerability
> > in its ping utility in 2022[2]. The impact of the vulnerability was mitigated
> > by FreeBSD's Capsicum sandboxing.
> >
> > The correct solution for the problem on Linux is to my knowledge to create a
> > pty/tty pair, but that is somewhat impractical for small utilities like ping, in
> > order to restrict themselves (they would need to create a sidecar process to
> > shovel the data back and forth). Workarounds include setsid() and seccomp-bpf,
> > but they also have their limits and are not a clean solution. We've previously
> > discussed it in [3].
> >
> > I do believe that requiring CAP_SYS_ADMIN for TIOCLINUX's TIOCL_PASTESEL subcode
> > would be a better approach than so many sudo-style and sandboxing tools having
> > to learn this lesson the hard way. Can we please reconsider this patch?
>
> Have you verified that nothing will break with this?
Not yet, but I am happy to try it out.
> If so, it needs to be submitted in a form that could be accepted (this
> one was not, so I couldn't take it even if I wanted to), and please add
> a tested-by from you and we will be glad to reconsider it.
Thanks, will do.
In my understanding from the thread, the outstanding problems that were
discussed were:
- compatibility with GPM -- I can try this out.
- clarification of why this is needed -- I hope the additional
discussion in this thread has clarified this.
- submittable "form"
By the non-submittable "form", I assume you mean the formatting and maybe
phrasing of the e-mail, so that it can be cleanly applied to git? Or was there
anything in the code which I missed?
Thanks,
—Günther
--
Sent using Mutt 🐕 Woof Woof
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
