kernel-hardening.lists.openwall.com archive mirror
 help / color / mirror / Atom feed
From: Peter Dolding <oiaohm@gmail.com>
To: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
Cc: "Serge E. Hallyn" <serge@hallyn.com>,
	Kees Cook <keescook@chromium.org>,
	Daniel Micay <danielmicay@gmail.com>, 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: Wed, 31 May 2017 21:27:49 +1000	[thread overview]
Message-ID: <CANA3KFWE2kUwdzGAGwRn8x4ceFzx5Z-quC2WBwqvks8LkTCh+A@mail.gmail.com> (raw)
In-Reply-To: <20170530225245.092497be@alans-desktop>

On Wed, May 31, 2017 at 7:52 AM, Alan Cox <gnomes@lxorguk.ukuu.org.uk> wrote:
>> > So tty stuff should under a tty capabilities.
>>
>> (last reply on this)
>>
>> Currently capabilities.7 says
>>
>>               * employ  the  TIOCSTI ioctl(2) to insert characters into the input queue of a
>>                 terminal other than the caller's controlling terminal;
>>
>> for CAP_SYS_ADMIN.
>>
>> So you can create a new CAP_SYS_TIOCSSTI if you like, and offer a patch where
>> *both* CAP_SYS_ADMIN and CAP_SYS_ADMIN suffice.  Again, see CAP_SYSLOG for a
>> prior example.
>
> Even then it wouldn't be useful because the attacker can use every other
> interface in the tty layer, many of which you can't magic away behind a
> capability bit. And the applications would need changing to use the
> feature - at which point any theoretical broken apps can instead be fixed
> to use a pty/tty pair and actually fix the real problem.
>
Alan is right.   CAP_SYS_ADMIN allows crossing the tty barrier.

Broken applications that you can wrap in a pty/tty pair as the lxc
application does would be defeated if those applications move up to
CAP_SYS_ADMIN.  Because you have granted the high right of cross
pty/tty containment.

Pushing CAP_SYS_TIOSSTI out by itself without the feature in
CAP_SYS_ADMIN means broken applications can be allowed to run in like
a lxc container where they cannot go anywhere with the exploit because
the pty/tty they are picking is not going to get them very far at all.

Pushing TIOSSTI up to CAP_SYS_ADMIN to address this problem is wrong.
 Question is also how many applications use CAP_SYS_ADMIN feature to
push chars into other pty/tty on the system.   Pushing across pty/tty
barrier may not be a suitable feature to be generically in
CAP_SYS_ADMIN in the first place.

http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/

This here is example of TIOSSTI pushback as CAP_SYS_ADMIN being bad.
I don't know of a genuine program using push back in exploiting way
where the pushed back input is expected to be processed after the
program has terminated.

Really we need to work out how many breakage will in fact be caused by
majority restricting both pushback and write across tty barrier.
This is not like CAP_SYS_LOG these are features that can be used to
exploit system badly.   It is possible that the exploiting form of
TIOSSTI pushback is used by nothing genuine userspace in any properly
functional case.   So if that is the case unconstrained TIOSSTI
push-back would only be making application crashes worse.

The reason I want TIOSSTI pushback moved to its own CAP_SYS first is
to find out if anything is in fact using it as part of genuine usage
and allowing anyone caught out to work around it.    I am sorry this
is me most likely using X11 logic break it and see if anyone yells.
If no one complains disappear the feature completely then this closes
this form of exploit for good.

Peter Dolding

  reply	other threads:[~2017-05-31 11:27 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
2017-05-30 15:52                             ` Serge E. Hallyn
2017-05-30 21:52                               ` Alan Cox
2017-05-31 11:27                                 ` Peter Dolding [this message]
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=CANA3KFWE2kUwdzGAGwRn8x4ceFzx5Z-quC2WBwqvks8LkTCh+A@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).