[kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
From: Alan Cox <hidden>
Date: 2017-06-01 21:26:51
Also in:
lkml
On Thu, 1 Jun 2017 12:18:58 -0500 "Serge E. Hallyn" [off-list ref] wrote:
Quoting Alan Cox (gnomes at lxorguk.ukuu.org.uk):quoted
quoted
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 doWhitelist 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.quoted
this with a kernel hook lets do it properly. Remember the namespace of the tty on creationMatt's patch does this,quoted
If the magic security flag is set then Apply a whitelist to *any* tty ioctl call where the ns doesn't matchSeems sensible.
I'm arguing that we need to swap the TIOCSTI test for a !whitelisted() test to go with the namespace difference check. Then it makes sense because we actually address the real problem. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html