From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751108AbdE3S2R (ORCPT ); Tue, 30 May 2017 14:28:17 -0400 Received: from emsm-gh1-uea10.nsa.gov ([8.44.101.8]:20821 "EHLO emsm-gh1-uea10.nsa.gov" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750811AbdE3S2N (ORCPT ); Tue, 30 May 2017 14:28:13 -0400 X-IronPort-AV: E=Sophos;i="5.38,419,1491264000"; d="scan'208";a="7564793" IronPort-PHdr: =?us-ascii?q?9a23=3AVrbwpBTUNIXI6ISzPIBtp13he9psv+yvbD5Q0YIu?= =?us-ascii?q?jvd0So/mwa67YRCPt8tkgFKBZ4jH8fUM07OQ6PG/HzBcqs/b7DgrS99lb1c9k8?= =?us-ascii?q?IYnggtUoauKHbQC7rUVRE8B9lIT1R//nu2YgB/Ecf6YEDO8DXptWZBUhrwOhBo?= =?us-ascii?q?KevrB4Xck9q41/yo+53Ufg5EmCexbal8IRiyrwjdrMYbjIRtJqos1BfErWZDdv?= =?us-ascii?q?hLy29vOV+dhQv36N2q/J5k/SRQuvYh+NBFXK7nYak2TqFWASo/PWwt68LlqRfM?= =?us-ascii?q?TQ2U5nsBSWoWiQZHAxLE7B7hQJj8tDbxu/dn1ymbOc32Sq00WSin4qx2RhLklD?= =?us-ascii?q?sLOjgk+2zMlMd+kLxUrw6gpxxnwo7bfoeVNOZlfqjAed8WXHdNUtpNWyBEBI6z?= =?us-ascii?q?YZEPD+4cNuhGqYfzqUYFoR+nCQWxGO/jzzlFjWL006InyeQsCQLI0hEgEdwQvn?= =?us-ascii?q?rbrtv1NKAOXu6yw6bGwi7Ob+9V1Drn9ITFaAwtrPOKULltccTR004vFwbdg1uN?= =?us-ascii?q?tYzqISuV1uQTvGid8uFuSOevhHQjqwF1vDeuxtonh47Sho0I0VDJ7jl5wYYpKt?= =?us-ascii?q?24T053e9ikEIBKuC2AOIt2Rd0iTnhutS0nxLMGvpu7czILyJQh3xPfbv2Hc5SS?= =?us-ascii?q?4h39TuqRJi14hH19dLK8mRmy606gxfP4VsWu11ZKtCVFn9/RvX4Ozxze8tWLR/?= =?us-ascii?q?Ry80u72TuDyhrf5v9LLEwqj6bXNpgsyaMqmJUJq0TMBCr2lV3zjK+Ra0or5PCl?= =?us-ascii?q?6//iYrX6vp+cMJJ0ih3mPqQuhMO/BeM4PxASX2eB4+S81aDj/VbjTLVWjvw5jq?= =?us-ascii?q?nZsJfAKcQduqG5GBNa3pwm6xa+CzeqyNUYnX8ZI1JZYB+LkofkNl7ULP34EPuz?= =?us-ascii?q?mUqgnTh1y/zcI7HtGpDNIWLCkLflc7Z98UlcyA8rwNBE+p1UEaoMIO7zW0DttN?= =?us-ascii?q?zYCQU1Mwqvw+n9Etl92YQeWXyXDq+DLKzSqUOI5v4oI+SUYI8VuTD9K+Uq5vL3?= =?us-ascii?q?jn82h0Udfa+30psTc324APtmLFuDYXb2gdcOD30KvgwgQ+zuklGCViRTZ3mqVa?= =?us-ascii?q?Im+j47EJ6mDZvERo21hLyB3SG7HoBZZ2xfEVCDD2vnd5ieW/cNdCKTItZtkjkD?= =?us-ascii?q?Vbe8Vo8h0Q+huRTky7poMOXU4DcUtZH929hv4e3cixUy+SZzD8SH3GGHV3t0kX?= =?us-ascii?q?8QRz8qwKB/plRwylSd3qhihfxXC9hT6+pJUgggL57T0vJ1C9bzWgLHcdeEU1Km?= =?us-ascii?q?QtS9ATEtVdI92dgOY15jFNWkgBHMxS6qA7sPm7OXA5w097rW32LtKMZl13bGyK?= =?us-ascii?q?4hgkElQsRRK2KmnbJw9w/UB47KiEiWi6aqdb4b3C7I9WeD0G+OsFtfUA5qXqXP?= =?us-ascii?q?RWofaVfOrdTl+kPCSKejCa85PQtbxs6NNLBHat3zglVCQPfiONLeb3itlGe3AB?= =?us-ascii?q?aC3qmMY5bye2UBwCXdD1AJkw8J/XmYOgg+BSehrnnaDDxvE1Lvfkzt8ed5qHOm?= =?us-ascii?q?SE870huFb1Fg17qy/B4Zn/ucS+kc3rgcoicuty10HEqh39LRE9ePvA5hfLhfYd?= =?us-ascii?q?wn+1dH1XzWtxJmM5y7Ma9ig0YefBptv0Pw1hV4FplAkdUxrH8w0AVyLqeY2ktb?= =?us-ascii?q?dzyExZDwJqHXKm7q8R+zcaHWwU/R0daN96cU9Ps4q0/svBynFkom7XpnycBZ3G?= =?us-ascii?q?eG6ZnQEAUSVpfxWF4t9xdmv7HafjU954TM2H1jN6m0tTrC1MwyBOY+zhahcNBf?= =?us-ascii?q?MLmLFA/vEM0WHdWuKO83m1i0dB4EO/pS9KEuM8O7dPuMwLSrM/p4nDK6kWRH55?= =?us-ascii?q?hw0keW+CpgVu7FxJAFw/SC0QubSzfwlkuussfymdMMWDcJA2DqyTT4HNwWIbN9?= =?us-ascii?q?cJxNCmq0JcCzgNJkiNnoUnxf7lKkAlRD2cmnflySc1n5jjFXgGEevWDvszG/0D?= =?us-ascii?q?o8xzQgsra32inH3/ikfx0CbCoDbW1rix/HJpj8298cW02ldCAthBy/6lv5gbVY?= =?us-ascii?q?ubk5KHPcB1pLKXvYNWZnB5Csu6KCbsgH05YhtSFaQazoelyBYqLsqBsdlSX4Fi?= =?us-ascii?q?1Rwy5tJGLigYnwgxEv0DHVF310tneMPJgpnRo=3D?= X-IPAS-Result: =?us-ascii?q?A2EIAwAvuC1Z/wHyM5BcGgEBAQECAQEBAQgBAQEBFgEBAQM?= =?us-ascii?q?BAQEJAQEBgwEpYoENg3KaTwEBAQEBAQaBJpd/CSELhXgCglRXAQEBAQEBAQECA?= =?us-ascii?q?QJoKIIzBQIDGgEFgjsBAQEBAgEjDwEbKxALDQsCAiYCAjEmBgEHCx0Eh2mCEwU?= =?us-ascii?q?IEKw/giYmAosmAQEBAQEBBAEBAQEBAQEBIIELhRCCJoMfgyWEVoJgBZ4jhyCMC?= =?us-ascii?q?IIGVYRng2CGVUiUBliBCicJAh8IIQ9GhTiBZiQ2AYdrgWcBAQE?= Message-ID: <1496169122.2164.21.camel@tycho.nsa.gov> Subject: Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN From: Stephen Smalley To: Matt Brown , Alan Cox Cc: Casey Schaufler , Boris Lukashev , Greg KH , "Serge E. Hallyn" , Kees Cook , kernel-hardening@lists.openwall.com, linux-security-module , linux-kernel Date: Tue, 30 May 2017 14:32:02 -0400 In-Reply-To: <2ab8580e-bf8e-21bd-6bfa-33e5fa82400b@nmatt.com> 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> Organization: National Security Agency Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.22.6 (3.22.6-2.fc25) Mime-Version: 1.0 Content-Transfer-Encoding: 8bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 2017-05-30 at 12:28 -0400, Matt Brown wrote: > On 5/30/17 8:24 AM, Alan Cox wrote: > > Look there are two problems here > > > > 1. TIOCSTI has users > > I don't see how this is a problem. > > > > > 2. You don't actually fix anything > > > > The underlying problem is that if you give your tty handle to > > another > > process which you don't trust you are screwed. It's fundamental to > > the > > design of the Unix tty model and it's made worse in Linux by the > > fact > > that we use the tty descriptor to access all sorts of other console > > state > > (which makes a ton of sense). > > > > Many years ago a few people got this wrong. All those apps got > > fixes back > > then. They allocate a tty/pty pair and create a new session over > > that. > > The potentially hostile other app only gets to screw itself. > > > > Many years ago? We already got one in 2017, as well as a bunch last > year. > See: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tiocsti > > > If it was only about TIOCSTI then your patch would still not make > > sense > > because you could use on of the existing LSMs to actually write > > yourself > > some rules about who can and can't use TIOCSTI. For that matter you > > can > > even use the seccomp feature today to do this without touching your > > kernel because the ioctl number is a value so you can just block > > ioctl > > with argument 2 of TIOCSTI. > > > > 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). > > > So please explain why we need an obscure kernel config option that > > normal > > users will not understand which protects against nothing and can be > > done already ? > > > > Alan > > > > -- > To unsubscribe from this list: send the line "unsubscribe linux- > security-module" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at  http://vger.kernel.org/majordomo-info.html From mboxrd@z Thu Jan 1 00:00:00 1970 From: sds@tycho.nsa.gov (Stephen Smalley) Date: Tue, 30 May 2017 14:32:02 -0400 Subject: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN In-Reply-To: <2ab8580e-bf8e-21bd-6bfa-33e5fa82400b@nmatt.com> 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> Message-ID: <1496169122.2164.21.camel@tycho.nsa.gov> To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On Tue, 2017-05-30 at 12:28 -0400, Matt Brown wrote: > On 5/30/17 8:24 AM, Alan Cox wrote: > > Look there are two problems here > > > > 1. TIOCSTI has users > > I don't see how this is a problem. > > > > > 2. You don't actually fix anything > > > > The underlying problem is that if you give your tty handle to > > another > > process which you don't trust you are screwed. It's fundamental to > > the > > design of the Unix tty model and it's made worse in Linux by the > > fact > > that we use the tty descriptor to access all sorts of other console > > state > > (which makes a ton of sense). > > > > Many years ago a few people got this wrong. All those apps got > > fixes back > > then. They allocate a tty/pty pair and create a new session over > > that. > > The potentially hostile other app only gets to screw itself. > > > > Many years ago? We already got one in 2017, as well as a bunch last > year. > See: https://cve.mitre.org/cgi-bin/cvekey.cgi?keyword=tiocsti > > > If it was only about TIOCSTI then your patch would still not make > > sense > > because you could use on of the existing LSMs to actually write > > yourself > > some rules about who can and can't use TIOCSTI. For that matter you > > can > > even use the seccomp feature today to do this without touching your > > kernel because the ioctl number is a value so you can just block > > ioctl > > with argument 2 of TIOCSTI. > > > > 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). > > > So please explain why we need an obscure kernel config option that > > normal > > users will not understand which protects against nothing and can be > > done already ? > > > > 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 -- 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