Message-ID: <20151220194211.219a152c@lxorguk.ukuu.org.uk>
Date:	Sun, 20 Dec 2015 19:42:11 +0000
From:	One Thousand Gnomes <gnomes@...rguk.ukuu.org.uk>
To:	Jann Horn <jann@...jh.net>
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

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

And the LSMs log it for good reason.

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

With the various filters and BPF we have today you can do extremely fine
grained protection.
 
> 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.

And the distributions will presumably not turn on your sysctl either,
because they won't know about it - and in the enterprise case it might
break back compatibility with some app.

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

The LSMs sit on top of DAC so code doesn't get duplicated.

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

So you are dealing with just a network connection. In which case

1. You shouldn't be logging in as root, and most systems don't allow it
in the first place

2. If you were you would exec su - username from root to the unprivileged
user and do actions,

3. If you really wanted to do it then you would allocate a pty/tty pair,
run the user process over that and then vhangup() on it, repeating for
each user you wanted to create sessions for.

> Can you elaborate on the "keyboard programming" bit?

With console access and the right permissions you can reprogram the
keyboard mappings. It's another way of adding extra events in a console
environment - doesn't apply in the ssh case. Another oddity is you can
make some terminals send back identification codes (VT series), although
these days most emulations have that disabled.

> 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 think every normal policy on that is already "Don't log in as root"

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

Assuming you trust the ssh client and and the ssh server then all the
bits are already there to allocate a new session over a pty/tty pair and
use that to get full isolation.

> 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

pty/tty pairs do exactly this.

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

SAK is not overridable so whatever you SAK key or sequence is you
interpret it within your trusted code (so the one that creates the
subshells and copies traffic to them). You don't need hacks like shell
prompt colours because you *know* that some sequence such as CTRL-^
*always* gets you to the controlling interface.

So you'd write a bit of C or Go or similar code to put the subshell on a
pty/tty pair, copy all bytes back and forth but always trap CTRL-^ or
similar, to go back to a control interface.

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

In VT terminal cases not that I know of. Some other terminal types can do
copies.

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

Powered by blists - more mailing lists