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

["Serge E. Hallyn" <serge@hallyn.com>]

Quoting Alan Cox (gnomes@lxorguk.ukuu.org.uk):
> > I still cannot wrap my head around why providing users with a
> > protection is a bad thing. Yes, the other tty games are bad, but this
> > fixes a specific and especially bad case that is easy to kill. It's
> > got a Kconfig and a sysctl. It's not on by default. This protects the
> > common case of privileged ttys that aren't attached to consoles, etc,
> 
> Which just leads to stuff not getting fixed. Like all the code out there
> today which is still vulnerable to selection based attacks because people
> didn't do the job right when "fixing" stuff because they are not
> thinking about security at a systems level but just tickboxing CVEs.
> 
> I'm not against doing something to protect the container folks, but that
> something as with Android is a whitelist of ioctls. And if we need to do

Whitelist of ioctls (at least using seccomp) is not sufficient because
then we have to turn the ioctl always-off.  But like you say we may want
to enable it for ptys which are created inside the container's user ns.

> this with a kernel hook lets do it properly.
> 
> Remember the namespace of the tty on creation

Matt's patch does this,

> If the magic security flag is set then
> 	Apply a whitelist to *any* tty ioctl call where the ns doesn't
> 		match

Seems sensible.

> and we might as well just take the Android whitelist since they've kindly
> built it for us all!
> 
> In the tty layer it ends up being something around 10 lines of code and
> some other file somewhere in security/ that's just a switch or similar
> with the whitelisted ioctl codes in it.
> 
> That (or a similar SELinux ruleset) would actually fix the problem.
> SELinux would be better because it can also apply the rules when doing
> things like su/sudo/...
> 
> Alan