Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1636790 > unrolled thread

[PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

Back to article view | Back to linux.kernel

Contents

  [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown <matt@nmatt.com> - 2017-05-06 01:30 +0200
    Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require  CAP_SYS_ADMIN Alan Cox <gnomes@lxorguk.ukuu.org.uk> - 2017-05-10 22:40 +0200
      Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make  TIOCSTI ioctl require CAP_SYS_ADMIN Daniel Micay <danielmicay@gmail.com> - 2017-05-10 23:10 +0200

#1636790 — [PATCH v6 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.

# 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

[toc] | [next] | [standalone]

#1639074 — Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Fri,  5 May 2017 19:20:16 -0400
Matt Brown <matt@nmatt.com> wrote:

> 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. 

And it still doesn't deal with the fact that there are hundreds of other
ways to annoy the owner of a tty if it's passed to a lower privilege
child from framebuffer reprogramming through keyboard remaps.

The proper way to handle those cases is to create a pty/tty pair and use
that. Your patch is pure snake oil and if anything implies safety that
doesn't exist.

In addition your change to allow it to be used by root in the guest
completely invalidates any protection you have because I can push

"rm -rf /\n"

as root in my namespace and exit

The tty buffers are not flushed across the context change so the shell
you return to gets the input and oh dear....

Alan

[toc] | [prev] | [next] | [standalone]

#1639082 — Re: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN

On Wed, 2017-05-10 at 21:29 +0100, Alan Cox wrote:
> 
> In addition your change to allow it to be used by root in the guest
> completely invalidates any protection you have because I can push
> 
> "rm -rf /\n"
> 
> as root in my namespace and exit
> 
> The tty buffers are not flushed across the context change so the shell
> you return to gets the input and oh dear....
> 
> Alan

I might be missing something, but it looks like the patch tracks where
the tty was created and only allows this with CAP_SYS_ADMIN in the ns
where the tty came from.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web