[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20170601171858.GA19604@mail.hallyn.com>
Date: Thu, 1 Jun 2017 12:18:58 -0500
From: "Serge E. Hallyn" <serge@...lyn.com>
To: Alan Cox <gnomes@...rguk.ukuu.org.uk>
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>,
"Serge E. Hallyn" <serge@...lyn.com>,
"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
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.
> 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
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.
