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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<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: [kernel-hardening] 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