[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1496169122.2164.21.camel@tycho.nsa.gov>
Date: Tue, 30 May 2017 14:32:02 -0400
From: Stephen Smalley <sds@...ho.nsa.gov>
To: Matt Brown <matt@...tt.com>, Alan Cox <gnomes@...rguk.ukuu.org.uk>
Cc: Casey Schaufler <casey@...aufler-ca.com>,
Boris Lukashev
<blukashev@...pervictus.com>,
Greg KH <gregkh@...uxfoundation.org>,
"Serge
E. Hallyn" <serge@...lyn.com>,
Kees Cook <keescook@...omium.org>, 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 Tue, 2017-05-30 at 12:28 -0400, Matt Brown wrote:
> On 5/30/17 8:24 AM, Alan Cox wrote:
> > Look there are two problems here
> >
> > 1. TIOCSTI has users
>
> I don't see how this is a problem.
>
> >
> > 2. You don't actually fix anything
> >
> > The underlying problem is that if you give your tty handle to
> > another
> > process which you don't trust you are screwed. It's fundamental to
> > the
> > design of the Unix tty model and it's made worse in Linux by the
> > fact
> > that we use the tty descriptor to access all sorts of other console
> > state
> > (which makes a ton of sense).
> >
> > Many years ago a few people got this wrong. All those apps got
> > fixes back
> > then. They allocate a tty/pty pair and create a new session over
> > that.
> > The potentially hostile other app only gets to screw itself.
> >
>
> Many years ago? We already got one in 2017, as well as a bunch last
> year.
> See: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tiocsti
>
> > If it was only about TIOCSTI then your patch would still not make
> > sense
> > because you could use on of the existing LSMs to actually write
> > yourself
> > some rules about who can and can't use TIOCSTI. For that matter you
> > can
> > even use the seccomp feature today to do this without touching your
> > kernel because the ioctl number is a value so you can just block
> > ioctl
> > with argument 2 of TIOCSTI.
> >
>
> Seccomp requires the program in question to "opt-in" so to speak and
> set
> certain restrictions on itself. However as you state above, any
> TIOCSTI
> protection doesn't matter if the program correctly allocates a
> tty/pty pair.
> This protections seeks to protect users from programs that don't do
> things
> correctly. Rather than killing bugs, this feature attempts to kill an
> entire
> bug class that shows little sign of slowing down in the world of
> containers and
> sandboxes.
Just FYI, you can also restrict TIOCSTI (or any other ioctl command)
via SELinux ioctl whitelisting, and Android is using that feature to
restrict TIOCSTI usage in Android O (at least based on the developer
previews to date, also in AOSP master).
>
> > So please explain why we need an obscure kernel config option that
> > normal
> > users will not understand which protects against nothing and can be
> > done already ?
> >
> > Alan
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-
> security-module" in
> the body of a message to majordomo@...r.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
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.
