Date:	Sun, 20 Dec 2015 20:16:45 +0100
From:	Jann Horn <jann@...jh.net>
To:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
Cc:	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.com>, linux-kernel@...r.kernel.org
Subject: Re: [PATCH] drivers/tty: add kernel.restrict_pushback sysctl

On Sun, Dec 20, 2015 at 04:36:43PM +0000, One Thousand Gnomes wrote:
> On Sun, 20 Dec 2015 16:45:26 +0100
> Jann Horn <jann@...jh.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.

Pretty much nothing in the kernel, at least outside of LSMs, logs
anything when an access is denied. IIRC I included logging in another
security patch that might break stuff and was asked to remove the
logging.

True, it looks like you can already do this with SELinux or probably
also Tomoyo. I didn't realize that it gives you that granularity.

I don't really like the idea of putting a hardening measure like this
into an LSM that many distros don't turn on by default, but I get your
point about duplicating existing functionality inconsistently.


> 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).

Eh. As far as I can tell, that doesn't take into account that the
shell might already have secrets in virtual memory or so, and it
would require the LSM to emulate the normal DAC checks for following
access checks with the creds of the tainting process, duplicating
quite a bit of security-relevant code.


> > 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.

I'm mostly concerned about servers where an admin logs in as root,
then changes to various users to configure different services,
because that's the typical multi-user environment - and you usually
don't have X there.

Can you elaborate on the "keyboard programming" bit?

> > 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.

The attack scenario I have in mind is "someone ssh'es into a server as
root, then changes to another user to run some commands". In this case,
the only potential leaks I see are the pty slave fd, the environment
and the cwd.

I'm aware that this is not as simple when X is involved.


> 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.

I think SAK wouldn't be so great because I don't see an easy solution to
make it work nicely with nested shells: E.g. if you ssh into a server,
then su to a lower privilege level on the server, you might want to get
back either to the local shell or to the remote shell.

I think a nicer way would be to allow creation of sub-tty files that are
bound to a "parent" tty, but whose connection to the parent tty can be
revoked. Then, either the shell or programs like sudo could ensure that
only such a sub-tty is passed down and that it is revoked before the
shell prompt is shown the next time. To ensure that the shell prompt is
not faked, a simple approach might be to show a small secret word and/or
color as part of the shell prompt. This way, the user wouldn't have to
do anything additional (like pressing the SAK) apart from checking the
prompt correctness.

Of course, this breaks if there is a way to tell the TTY to copy some
old prompt to the bottom of the screen. Does anything like that exist?
I'm not familiar enough with TTYs to know the answer.


> 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.

Download attachment "signature.asc" of type "application/pgp-signature" (820 bytes)

Powered by blists - more mailing lists