Quoting Alan Cox (gno...@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
