linux-kernel - Re: [kernel-hardening] Re: [PATCH v6 0/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: <CANA3KFXVzSXuA4Cocm7fUYE9EOvJX7pW0bsj=cgyUYvScUsXGQ@mail.gmail.com>
Date:   Mon, 29 May 2017 20:42:19 +1000
From:   Peter Dolding <oiaohm@...il.com>
To:     "Serge E. Hallyn" <serge@...lyn.com>
Cc:     Kees Cook <keescook@...omium.org>,
        Daniel Micay <danielmicay@...il.com>,
        Alan Cox <gnomes@...rguk.ukuu.org.uk>,
        Matt Brown <matt@...tt.com>,
        Greg KH <gregkh@...uxfoundation.org>,
        Jiri Slaby <jslaby@...e.com>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jann Horn <jannh@...gle.com>, James Morris <jmorris@...ei.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 v6 0/2] security: tty: make TIOCSTI
 ioctl require CAP_SYS_ADMIN

On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn <serge@...lyn.com> wrote:
> On Fri, May 19, 2017 at 12:48:17PM +1000, Peter Dolding wrote:
>> Using cap_sys_admin as fix is like removing car windsheld because
>> vision is being blocked by a rock hitting it.
>
> Nonsense.  If the application has cap_sys_admin then it is less contained and
> more trusted anyway.  If I went to the trouble to run an application in a
> private user namespace (where it can have cap_sys_admin, but not targeted
> at my tty) then it should be more contained.  That's the point of targeted
> capabilities.

The thing that is missed every time is how much is cap_sys_admin.

So you are saying a user namespace has to be set up to contain the defect.

Really no application should have cap_sys_admin.

The theory of capabilities is that security should be broken down into
logical blocks.

So tty stuff should under a tty capabilities.

This one here should not be shoved into cap_sys_admin because can you
show a single case of a general used application performing this
action in the exploit way that is normal behaviour.

The exploits are doing behaviours that have no general place.

Its really simple to shove everything to cap_sys_admin instead of hey
lets look at the exploits how they work and if this should be fairly
blanked banned.  The behaviour that is question is being able push
chars into input stream and have them processed after application has
terminated or after application has switched to background.   That is
not pushing data into another tty.   Pushing data into a different tty
is already restricted to cap_sys_admin.

Personally from my point of view when application terminates or
switches to background  what ever it pushed back into the input buffer
should be junked and maybe a special cap to deal with rare case of
applications that expect this behavour.

Also please remember one of the application using this behaviour of
pushing stuff back to input buffer is csh.  In other words a general
user shell.   This will not be the only application that is general
usage after the change of pushing to cap_sys_admin that would also
have to be pushed to cap_sys_admin because they use TIOCSTI in a way
that the patch will block when the program does not have
cap_sys_admin.   So now you have more applications running as
cap_sys_admin so more security problems.

Peter Dolding.