From: Alan Cox <gnomes@lxorguk.ukuu.org.uk> To: Peter Dolding <oiaohm@gmail.com> 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 15:36:15 +0100 [thread overview] Message-ID: <20170531153615.37fea64a@alans-desktop> (raw) In-Reply-To: <CANA3KFWE2kUwdzGAGwRn8x4ceFzx5Z-quC2WBwqvks8LkTCh+A@mail.gmail.com> > Alan is right. CAP_SYS_ADMIN allows crossing the tty barrier. I don't need CAP_ anything to mmap your frame buffer, or use selection to cut and paste text into the terminal. > 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. Yes > 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. So there are two real problems here 1. We don't know what namespace each character belongs to, so there's no way we can construct a model where pushed symbols only appear in the namespace they are pushed from. That would be a nice situation but it's not at all obvious there is a sane way to implement it. 2. Focussing on TIOCSTI is just ignoring the bigger picture. TIOCSTI is actually a lot less nasty in many situations than a framebuffer mmap and spying attack where a container run from the console could sit and watch you. TIOCSTI is in some ways the easiest to fix because setsid() will let you mitigate it in certain cases whereas I'm fairly sure the selection based console attack doesn't need controlling terminal rights. In the case you have a less privileged subshell you need a whole new tty context, and there's no obvious way for the kernel to magic one into existance so that for example the container can change it's own baud rate but not the baud rate of any app outside the container. ioctl whitelisting will break stuff, but an SELinux/AppArmour/seccomp whitelisting based solution is probably the only practical one you can implement usefully, and for a lot of container users would be ok. And yes there are genuine users of TIOCSTI although these days most things just use their own pty/tty pair. Alan
WARNING: multiple messages have this Message-ID (diff)
From: gnomes@lxorguk.ukuu.org.uk (Alan Cox) To: linux-security-module@vger.kernel.org Subject: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Date: Wed, 31 May 2017 15:36:15 +0100 [thread overview] Message-ID: <20170531153615.37fea64a@alans-desktop> (raw) In-Reply-To: <CANA3KFWE2kUwdzGAGwRn8x4ceFzx5Z-quC2WBwqvks8LkTCh+A@mail.gmail.com> > Alan is right. CAP_SYS_ADMIN allows crossing the tty barrier. I don't need CAP_ anything to mmap your frame buffer, or use selection to cut and paste text into the terminal. > 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. Yes > 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. So there are two real problems here 1. We don't know what namespace each character belongs to, so there's no way we can construct a model where pushed symbols only appear in the namespace they are pushed from. That would be a nice situation but it's not at all obvious there is a sane way to implement it. 2. Focussing on TIOCSTI is just ignoring the bigger picture. TIOCSTI is actually a lot less nasty in many situations than a framebuffer mmap and spying attack where a container run from the console could sit and watch you. TIOCSTI is in some ways the easiest to fix because setsid() will let you mitigate it in certain cases whereas I'm fairly sure the selection based console attack doesn't need controlling terminal rights. In the case you have a less privileged subshell you need a whole new tty context, and there's no obvious way for the kernel to magic one into existance so that for example the container can change it's own baud rate but not the baud rate of any app outside the container. ioctl whitelisting will break stuff, but an SELinux/AppArmour/seccomp whitelisting based solution is probably the only practical one you can implement usefully, and for a lot of container users would be ok. And yes there are genuine users of TIOCSTI although these days most things just use their own pty/tty pair. Alan -- To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to majordomo at vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2017-05-31 14:37 UTC|newest] Thread overview: 89+ messages / expand[flat|nested] mbox.gz Atom feed top 2017-05-05 23:20 [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown 2017-05-05 23:20 ` [kernel-hardening] " Matt Brown 2017-05-05 23:20 ` Matt Brown 2017-05-05 23:20 ` [PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct Matt Brown 2017-05-05 23:20 ` [kernel-hardening] " Matt Brown 2017-05-05 23:20 ` Matt Brown 2017-05-05 23:20 ` [PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown 2017-05-05 23:20 ` [kernel-hardening] " Matt Brown 2017-05-05 23:20 ` Matt Brown 2017-05-18 13:31 ` Greg KH 2017-05-18 13:31 ` [kernel-hardening] " Greg KH 2017-05-18 13:31 ` Greg KH 2017-05-19 4:51 ` Matt Brown 2017-05-19 4:51 ` [kernel-hardening] " Matt Brown 2017-05-19 4:51 ` Matt Brown 2017-05-10 20:29 ` [PATCH v6 0/2] " Alan Cox 2017-05-10 20:29 ` [kernel-hardening] " Alan Cox 2017-05-10 20:29 ` Alan Cox 2017-05-10 21:02 ` [kernel-hardening] " Daniel Micay 2017-05-10 21:02 ` Daniel Micay 2017-05-13 19:52 ` Matt Brown 2017-05-13 19:52 ` [kernel-hardening] " Matt Brown 2017-05-13 19:52 ` Matt Brown 2017-05-15 4:45 ` [kernel-hardening] " Nicolas Belouin 2017-05-15 20:57 ` Alan Cox 2017-05-15 20:57 ` [kernel-hardening] " Alan Cox 2017-05-15 20:57 ` Alan Cox 2017-05-15 23:10 ` Peter Dolding 2017-05-15 23:10 ` [kernel-hardening] " Peter Dolding 2017-05-15 23:10 ` Peter Dolding 2017-05-16 4:15 ` Matt Brown 2017-05-16 4:15 ` [kernel-hardening] " Matt Brown 2017-05-16 4:15 ` Matt Brown 2017-05-16 9:01 ` Peter Dolding 2017-05-16 9:01 ` [kernel-hardening] " Peter Dolding 2017-05-16 9:01 ` Peter Dolding 2017-05-16 12:22 ` Matt Brown 2017-05-16 12:22 ` [kernel-hardening] " Matt Brown 2017-05-16 12:22 ` Matt Brown 2017-05-16 14:28 ` Kees Cook 2017-05-16 14:28 ` [kernel-hardening] " Kees Cook 2017-05-16 14:28 ` Kees Cook 2017-05-16 15:48 ` [kernel-hardening] " Serge E. Hallyn 2017-05-16 15:48 ` Serge E. Hallyn 2017-05-16 15:48 ` Serge E. Hallyn 2017-05-16 22:05 ` Peter Dolding 2017-05-16 22:05 ` Peter Dolding 2017-05-16 22:05 ` Peter Dolding 2017-05-16 21:43 ` Peter Dolding 2017-05-16 21:43 ` [kernel-hardening] " Peter Dolding 2017-05-16 21:43 ` Peter Dolding 2017-05-16 21:54 ` Matt Brown 2017-05-16 21:54 ` [kernel-hardening] " Matt Brown 2017-05-16 21:54 ` Matt Brown 2017-05-17 16:41 ` Alan Cox 2017-05-17 16:41 ` [kernel-hardening] " Alan Cox 2017-05-17 16:41 ` Alan Cox 2017-05-17 18:25 ` [kernel-hardening] " Daniel Micay 2017-05-17 18:25 ` Daniel Micay 2017-05-17 18:25 ` Daniel Micay 2017-05-17 23:04 ` Boris Lukashev 2017-05-18 3:18 ` Kees Cook 2017-05-18 3:18 ` Kees Cook 2017-05-18 3:18 ` Kees Cook 2017-05-19 2:48 ` Peter Dolding 2017-05-19 2:48 ` Peter Dolding 2017-05-19 2:48 ` Peter Dolding 2017-05-19 4:08 ` Boris Lukashev 2017-05-19 14:33 ` Serge E. Hallyn 2017-05-19 14:33 ` Serge E. Hallyn 2017-05-19 14:33 ` Serge E. Hallyn 2017-05-29 10:42 ` Peter Dolding 2017-05-29 10:42 ` Peter Dolding 2017-05-29 10:42 ` Peter Dolding 2017-05-30 15:52 ` Serge E. Hallyn 2017-05-30 15:52 ` Serge E. Hallyn 2017-05-30 15:52 ` Serge E. Hallyn 2017-05-30 21:52 ` Alan Cox 2017-05-30 21:52 ` Alan Cox 2017-05-30 21:52 ` Alan Cox 2017-05-31 11:27 ` Peter Dolding 2017-05-31 11:27 ` Peter Dolding 2017-05-31 11:27 ` Peter Dolding 2017-05-31 14:36 ` Alan Cox [this message] 2017-05-31 14:36 ` Alan Cox 2017-05-31 14:36 ` Alan Cox 2017-05-31 15:32 ` Serge E. Hallyn 2017-05-31 15:32 ` Serge E. Hallyn 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=20170531153615.37fea64a@alans-desktop \ --to=gnomes@lxorguk.ukuu.org.uk \ --cc=akpm@linux-foundation.org \ --cc=danielmicay@gmail.com \ --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=oiaohm@gmail.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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.