Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

[Alan Cox]

> Alan is right.   CAP_SYS_ADMIN allows crossing the tty barrier.

I don't need CAP_ anything to mmap your frame buffer, or use selection to
cut and paste text into the terminal.

> Broken applications that you can wrap in a pty/tty pair as the lxc
> application does would be defeated if those applications move up to
> CAP_SYS_ADMIN.  Because you have granted the high right of cross
> pty/tty containment.

Yes

> I don't know of a genuine program using push back in exploiting way
> where the pushed back input is expected to be processed after the
> program has terminated.

So there are two real problems here

1. We don't know what namespace each character belongs to, so there's no
way we can construct a model where pushed symbols only appear in the
namespace they are pushed from. That would be a nice situation but it's
not at all obvious there is a sane way to implement it.

2. Focussing on TIOCSTI is just ignoring the bigger picture. TIOCSTI is
actually a lot less nasty in many situations than a framebuffer mmap and
spying attack where a container run from the console could sit and watch
you. TIOCSTI is in some ways the easiest to fix because setsid() will let
you mitigate it in certain cases whereas I'm fairly sure the selection
based console attack doesn't need controlling terminal rights.

In the case you have a less privileged subshell you need a whole new tty
context, and there's no obvious way for the kernel to magic one into
existance so that for example the container can change it's own baud rate
but not the baud rate of any app outside the container.

ioctl whitelisting will break stuff, but an SELinux/AppArmour/seccomp
whitelisting based solution is probably the only practical one you can
implement usefully, and for a lot of container users would be ok.

And yes there are genuine users of TIOCSTI although these days most
things just use their own pty/tty pair.

Alan