Date: Sun, 20 Dec 2015 16:36:43 +0000
From: One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk>
To: Jann Horn <jann@thejh.net>
Cc: Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
        Jiri Slaby <jslaby@suse.com>, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] drivers/tty: add kernel.restrict_pushback sysctl
Message-ID: <20151220163643.6f939c6f@lxorguk.ukuu.org.uk>
In-Reply-To: <1450626326-8073-1-git-send-email-jann@thejh.net>
References: <1450626326-8073-1-git-send-email-jann@thejh.net>
Organization: Intel Corporation
MIME-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 3140
Lines: 69

On Sun, 20 Dec 2015 16:45:26 +0100
Jann Horn <jann@thejh.net> wrote:

> This new sysctl can be set to 1 to require CAP_SYS_ADMIN for
> the TIOCSTI ioctl (which lets the caller push input back into
> the TTY and thereby fake input to other processes that read
> from the same TTY).

You can already do tbis with an LSM, you don't need to add random
unstructured extra options nobody will know about. Your extra code also
doesn't log anything so the user who does hit a usage case will have
nightmares debugging it.

Am LSM can also do the job properly because it can use labels to
ascertain the action to perform dependant upon the tty and how it is
currently being used. An LSM can also protect you far better as it can
taint the input (for example it can arrange that any TIOCSTI input
character from a non root user causes the receiving process to be
untrusted - so you attach the su session and your input just makes the
shell executing it untrusted so unable to run the command).

> This is a well-known problem that hasn't been handled
> particularly well in userland, e.g. allowing a user to whose
> account root switches using "su" (or using "sudo" in the
> default config) to write input to root's shell, resulting
> in a privilege escalation. Additionally, it has increased

And the same attack works via X events and keyboard programming games. If
you leak file handles you lose. Again an LSM can mitigate here in ways
your sysctl can't.

> Note that this does not make it completely safe to leak pty
> FDs to unprivileged code: They could still be used to steal
> passwords that the user enters in his terminal, to
> selectively suppress keystrokes or to just fake program
> output. An automatic kernel-side solution to this, if it is
> even possible, would probably be complicated.

This is precisely the problem I have with this - it's airport security,
it sounds good but has no value at all. Remember that anyone wanting to
attack you today is using scripts so a week after your sysctl appears the
script will be updated and everyone's robots will have the new attack that
bypasses it.

So instead of attacking a leaked pty/tty handle the opponent uses the
leaked X11 handle and posts X events, or if its a console fd they use the
console interfaces to fake up keypresses.

There are IMHO two things you need to make any attempt to solve this
properly in the usual circumstances

- You need a secure event channel between the keyboard and the root shell
  you create

- You need a way to switch reliably to that secure channel

That all comes down to having usable SAK (secure attention keu) support.
With the current graphics DRM and with Wayland we are actually fairly
close to that being feasible. Until then anyone who types su on an
untrusted console is (and always has been) asking for trouble.

As an aside - you also need to include documentation if adding sysctls.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/