[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170601222628.6e101a34@lxorguk.ukuu.org.uk>
Date: Thu, 1 Jun 2017 22:26:28 +0100
From: Alan Cox <gnomes@...rguk.ukuu.org.uk>
To: "Serge E. Hallyn" <serge@...lyn.com>
Cc: Kees Cook <keescook@...omium.org>, Matt Brown <matt@...tt.com>,
Casey
Schaufler <casey@...aufler-ca.com>,
Boris Lukashev
<blukashev@...pervictus.com>,
Greg KH <gregkh@...uxfoundation.org>,
"kernel-hardening@...ts.openwall.com"
<kernel-hardening@...ts.openwall.com>,
linux-security-module
<linux-security-module@...r.kernel.org>,
linux-kernel
<linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH v7 2/2] security: tty: make
TIOCSTI ioctl require CAP_SYS_ADMIN
On Thu, 1 Jun 2017 12:18:58 -0500
"Serge E. Hallyn" <serge@...lyn.com> wrote:
> Quoting Alan Cox (gnomes@...rguk.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
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
