Date: Wed, 31 May 2017 21:27:49 +1000 From: Peter Dolding <oiaohm@...il.com> To: Alan Cox <gnomes@...rguk.ukuu.org.uk> Cc: "Serge E. Hallyn" <serge@...lyn.com>, Kees Cook <keescook@...omium.org>, Daniel Micay <danielmicay@...il.com>, Matt Brown <matt@...tt.com>, Greg KH <gregkh@...uxfoundation.org>, Jiri Slaby <jslaby@...e.com>, Andrew Morton <akpm@...ux-foundation.org>, Jann Horn <jannh@...gle.com>, James Morris <jmorris@...ei.org>, "kernel-hardening@...ts.openwall.com" <kernel-hardening@...ts.openwall.com>, linux-security-module <linux-security-module@...r.kernel.org>, linux-kernel <linux-kernel@...r.kernel.org> Subject: Re: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN On Wed, May 31, 2017 at 7:52 AM, Alan Cox <gnomes@...rguk.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
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.