From: Matt Brown <matt@nmatt.com>
To: serge@hallyn.com, gregkh@linuxfoundation.org, jslaby@suse.com,
akpm@linux-foundation.org, jannh@google.com,
keescook@chromium.org
Cc: jmorris@namei.org, kernel-hardening@lists.openwall.com,
linux-security-module@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: [kernel-hardening] [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
Date: Fri, 5 May 2017 19:20:16 -0400 [thread overview]
Message-ID: <20170505232018.28846-1-matt@nmatt.com> (raw)
This patchset introduces the tiocsti_restrict sysctl, whose default is
controlled via CONFIG_SECURITY_TIOCSTI_RESTRICT. When activated, this
control restricts all TIOCSTI ioctl calls from non CAP_SYS_ADMIN users.
This patch was inspired from GRKERNSEC_HARDEN_TTY.
This patch would have prevented
https://bugzilla.redhat.com/show_bug.cgi?id=1411256 under the following
conditions:
* non-privileged container
* container run inside new user namespace
Possible effects on userland:
There could be a few user programs that would be effected by this
change.
See: <https://codesearch.debian.net/search?q=ioctl%5C%28.*TIOCSTI>
notable programs are: agetty, csh, xemacs and tcsh
However, I still believe that this change is worth it given that the
Kconfig defaults to n. This will be a feature that is turned on for the
same reason that people activate it when using grsecurity. Users of this
opt-in feature will realize that they are choosing security over some OS
features like unprivileged TIOCSTI ioctls, as should be clear in the
Kconfig help message.
Threat Model/Patch Rational:
>From grsecurity's config for GRKERNSEC_HARDEN_TTY.
| There are very few legitimate uses for this functionality and it
| has made vulnerabilities in several 'su'-like programs possible in
| the past. Even without these vulnerabilities, it provides an
| attacker with an easy mechanism to move laterally among other
| processes within the same user's compromised session.
So if one process within a tty session becomes compromised it can follow
that additional processes, that are thought to be in different security
boundaries, can be compromised as a result. When using a program like su
or sudo, these additional processes could be in a tty session where TTY file
descriptors are indeed shared over privilege boundaries.
This is also an excellent writeup about the issue:
<http://www.halfdog.net/Security/2012/TtyPushbackPrivilegeEscalation/>
When user namespaces are in use, the check for the capability
CAP_SYS_ADMIN is done against the user namespace that originally opened
the tty.
# Changes since v5:
* added acks/reviews
# Changes since v4:
* fixed typo
# Changes since v3:
* use get_user_ns and put_user_ns to take and drop references to the owner
user namespace because CONFIG_USER_NS is an option
# Changes since v2:
* take/drop reference to user namespace on tty struct alloc/free to prevent
use-after-free.
# Changes since v1:
* added owner_user_ns to tty_struct to enable capability checks against
the namespace that created the tty.
* rewording in different places to make patchset purpose clear
* Added Documentation
next reply other threads:[~2017-05-05 23:20 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 23:20 Matt Brown [this message]
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
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=20170505232018.28846-1-matt@nmatt.com \
--to=matt@nmatt.com \
--cc=akpm@linux-foundation.org \
--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=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).