kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Peter Dolding <oiaohm@gmail.com>
To: "Serge E. Hallyn" <serge@hallyn.com>
Cc: Kees Cook <keescook@chromium.org>,
	Daniel Micay <danielmicay@gmail.com>,
	Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
	Matt Brown <matt@nmatt.com>, Greg KH <gregkh@linuxfoundation.org>,
	Jiri Slaby <jslaby@suse.com>,
	Andrew Morton <akpm@linux-foundation.org>,
	Jann Horn <jannh@google.com>, James Morris <jmorris@namei.org>,
	"kernel-hardening@lists.openwall.com"
	<kernel-hardening@lists.openwall.com>,
	linux-security-module <linux-security-module@vger.kernel.org>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
Date: Mon, 29 May 2017 20:42:19 +1000	[thread overview]
Message-ID: <CANA3KFXVzSXuA4Cocm7fUYE9EOvJX7pW0bsj=cgyUYvScUsXGQ@mail.gmail.com> (raw)
In-Reply-To: <20170519143344.GA15983@mail.hallyn.com>

On Sat, May 20, 2017 at 12:33 AM, Serge E. Hallyn <serge@hallyn.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.

  reply	other threads:[~2017-05-29 10:42 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-05 23:20 [kernel-hardening] [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown
2017-05-05 23:20 ` [kernel-hardening] [PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct Matt Brown
2017-05-05 23:20 ` [kernel-hardening] [PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown
2017-05-18 13:31   ` [kernel-hardening] " Greg KH
2017-05-19  4:51     ` Matt Brown
2017-05-10 20:29 ` [kernel-hardening] Re: [PATCH v6 0/2] " Alan Cox
2017-05-10 21:02   ` Daniel Micay
2017-05-13 19:52   ` Matt Brown
2017-05-15  4:45     ` Nicolas Belouin
2017-05-15 20:57     ` Alan Cox
2017-05-15 23:10       ` Peter Dolding
2017-05-16  4:15         ` Matt Brown
2017-05-16  9:01           ` Peter Dolding
2017-05-16 12:22             ` Matt Brown
2017-05-16 14:28               ` Kees Cook
2017-05-16 15:48                 ` Serge E. Hallyn
2017-05-16 22:05                   ` Peter Dolding
2017-05-16 21:43                 ` Peter Dolding
2017-05-16 21:54                   ` Matt Brown
2017-05-17 16:41                 ` Alan Cox
2017-05-17 18:25                   ` Daniel Micay
2017-05-17 23:04                     ` Boris Lukashev
2017-05-18  3:18                     ` Kees Cook
2017-05-19  2:48                       ` Peter Dolding
2017-05-19  4:08                         ` Boris Lukashev
2017-05-19 14:33                         ` Serge E. Hallyn
2017-05-29 10:42                           ` Peter Dolding [this message]
2017-05-30 15:52                             ` Serge E. Hallyn
2017-05-30 21:52                               ` Alan Cox
2017-05-31 11:27                                 ` Peter Dolding
2017-05-31 14:36                                   ` Alan Cox
2017-05-31 15:32                                     ` Serge E. Hallyn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CANA3KFXVzSXuA4Cocm7fUYE9EOvJX7pW0bsj=cgyUYvScUsXGQ@mail.gmail.com' \
    --to=oiaohm@gmail.com \
    --cc=akpm@linux-foundation.org \
    --cc=danielmicay@gmail.com \
    --cc=gnomes@lxorguk.ukuu.org.uk \
    --cc=gregkh@linuxfoundation.org \
    --cc=jannh@google.com \
    --cc=jmorris@namei.org \
    --cc=jslaby@suse.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=matt@nmatt.com \
    --cc=serge@hallyn.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).