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: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20170602210544.73680be8@lxorguk.ukuu.org.uk>
Date:   Fri, 2 Jun 2017 21:05:44 +0100
From:   Alan Cox <gnomes@...rguk.ukuu.org.uk>
To:     Matt Brown <matt@...tt.com>
Cc:     "Serge E. Hallyn" <serge@...lyn.com>,
        Kees Cook <keescook@...omium.org>,
        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: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make
 TIOCSTI ioctl require CAP_SYS_ADMIN

> Can't we also have a sysctl that toggles if CAP_SYS_ADMIN is involved in
> this whitelist check? Otherwise someone might leave things out of the
> whitelist just because they want to use those ioctls as a privileged
> process. Also restricting a privileged user from ioctls with this
> whitelist approach is going to be pointless because, if the whitelist is
> configurable from userspace, they will just be able to modify the
> whitelist.

Something like CAP_SYS_ADMIN is fine if you must have it configurable on
the grounds that CAP_SYS_ADMIN will let you override the list anyway.

> I'm fine with moving this to an LSM that whitelists ioctls. I also want
> to understand what a whitelist would like look and how you would
> configure it? Does a sysctl that is a list of allowed ioctls work? I
> don't want to just have a static whitelist that you can't change without
> recompiling your kernel.

That's odd because your previous argument was for a fixed one entry
whitelist containing TIOCSTI 8)

The list can probably be fixed. IMHO those wanting to do cleverer stuff
sre inevitably going to end up using a "grown up" LSM for the job because

a) they'll want to shape things like su not just containers
b) they will have cases where you want to lock down cleverly - eg you can
disable TIOCSTI use except by certain apps, and make those apps non
ptraceable so only existing real users of it can continue to use it.

For the whitelist you want most of the standard tty ioctls, but none of
the device specific ones, none of the hardware configuration ones, no
TIOCSTI, no selection, no line discipline change (or you can set a
network ldisc or various other evil and fascinating things).

I really think that for container type uses the whitelist can be fairly
clearly defined because we know a container isn't supposed to be screwing
with the hardware of the parent, configuring network interfaces or
pushing data to trip people up.

If we are prepared to accept nuisance attacks (messing up baud rate,
hangup, etc) then it's fairly easy to fix.

So I'd say it's all the generic tty ioctls except TIOCSTI and TIOCSETD
but it would be good to see what Android is going with and why.

You can still do some typeback stuff even then because the consoles and
terminals have ranges of query and requests you can trigger. As you can
use termios to absorb some symbols in the reply and map which one to use
for newline you can even type stuff. However it's very limited - hex
digits, [, c and some other oddments. People have looked hard at that and
I've yet to see a successful attack. Yes I can make you run test (aka
'[') but I've yet to see a way to use it for anything.

Alan