Date: Mon, 29 May 2017 17:37:58 -0400 From: Matt Brown <matt@...tt.com> To: gregkh@...uxfoundation.org, serge@...lyn.com, keescook@...omium.org Cc: kernel-hardening@...ts.openwall.com, linux-security-module@...r.kernel.org, linux-kernel@...r.kernel.org Subject: [PATCH v7 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN 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. # Integration with CRIU: * The CRIU dev team was contacted about any possible issues that restrict_tiocsti might cause for the CRIU program. Their response was that CRIU currently does not utilize the tiocsti ioctl, so it doesn't affect them at the moment. They do wish in the future to do checks against owner_user_ns, so we will work together on a way to make this information available to userspace. In the mean time, The CRIU team is OK with this patch moving forward as is. # Changes since v6: * fixed style issues * changed error message to use dev_warn_ratelimited # 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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.