From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751126AbdE3SoY (ORCPT ); Tue, 30 May 2017 14:44:24 -0400 Received: from mail-wr0-f172.google.com ([209.85.128.172]:35302 "EHLO mail-wr0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750871AbdE3SoV (ORCPT ); Tue, 30 May 2017 14:44:21 -0400 MIME-Version: 1.0 In-Reply-To: <1496169122.2164.21.camel@tycho.nsa.gov> References: <20170529213800.29438-1-matt@nmatt.com> <20170529213800.29438-3-matt@nmatt.com> <20170529232640.16211960@alans-desktop> <3738951f-7a4a-b37f-c695-21a2fcd45f76@schaufler-ca.com> <0e078ce7-5b62-f27c-3920-efc2ffdf342b@nmatt.com> <20170530132427.016053da@alans-desktop> <2ab8580e-bf8e-21bd-6bfa-33e5fa82400b@nmatt.com> <1496169122.2164.21.camel@tycho.nsa.gov> From: Nick Kralevich Date: Tue, 30 May 2017 11:44:18 -0700 Message-ID: Subject: Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN To: Stephen Smalley Cc: Matt Brown , Alan Cox , Casey Schaufler , Boris Lukashev , Greg KH , "Serge E. Hallyn" , Kees Cook , kernel-hardening@lists.openwall.com, linux-security-module , linux-kernel Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, May 30, 2017 at 11:32 AM, Stephen Smalley wrote: >> Seccomp requires the program in question to "opt-in" so to speak and >> set >> certain restrictions on itself. However as you state above, any >> TIOCSTI >> protection doesn't matter if the program correctly allocates a >> tty/pty pair. >> This protections seeks to protect users from programs that don't do >> things >> correctly. Rather than killing bugs, this feature attempts to kill an >> entire >> bug class that shows little sign of slowing down in the world of >> containers and >> sandboxes. > > Just FYI, you can also restrict TIOCSTI (or any other ioctl command) > via SELinux ioctl whitelisting, and Android is using that feature to > restrict TIOCSTI usage in Android O (at least based on the developer > previews to date, also in AOSP master). For reference, this is https://android-review.googlesource.com/306278 , where we moved to a whitelist for handling ioctls for ptys. -- Nick From mboxrd@z Thu Jan 1 00:00:00 1970 From: nnk@google.com (Nick Kralevich) Date: Tue, 30 May 2017 11:44:18 -0700 Subject: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN In-Reply-To: <1496169122.2164.21.camel@tycho.nsa.gov> References: <20170529213800.29438-1-matt@nmatt.com> <20170529213800.29438-3-matt@nmatt.com> <20170529232640.16211960@alans-desktop> <3738951f-7a4a-b37f-c695-21a2fcd45f76@schaufler-ca.com> <0e078ce7-5b62-f27c-3920-efc2ffdf342b@nmatt.com> <20170530132427.016053da@alans-desktop> <2ab8580e-bf8e-21bd-6bfa-33e5fa82400b@nmatt.com> <1496169122.2164.21.camel@tycho.nsa.gov> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, May 30, 2017 at 11:32 AM, Stephen Smalley wrote: >> Seccomp requires the program in question to "opt-in" so to speak and >> set >> certain restrictions on itself. However as you state above, any >> TIOCSTI >> protection doesn't matter if the program correctly allocates a >> tty/pty pair. >> This protections seeks to protect users from programs that don't do >> things >> correctly. Rather than killing bugs, this feature attempts to kill an >> entire >> bug class that shows little sign of slowing down in the world of >> containers and >> sandboxes. > > Just FYI, you can also restrict TIOCSTI (or any other ioctl command) > via SELinux ioctl whitelisting, and Android is using that feature to > restrict TIOCSTI usage in Android O (at least based on the developer > previews to date, also in AOSP master). For reference, this is https://android-review.googlesource.com/306278 , where we moved to a whitelist for handling ioctls for ptys. -- Nick -- 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