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

Alan Cox gnomes at lxorguk.ukuu.org.uk
Thu Jun 1 21:26:28 UTC 2017


On Thu, 1 Jun 2017 12:18:58 -0500
"Serge E. Hallyn" <serge at hallyn.com> wrote:

> Quoting Alan Cox (gnomes at 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.

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



More information about the Linux-security-module-archive mailing list