From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751037AbdE3X7Z (ORCPT ); Tue, 30 May 2017 19:59:25 -0400 Received: from relay6-d.mail.gandi.net ([217.70.183.198]:40836 "EHLO relay6-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750930AbdE3X7W (ORCPT ); Tue, 30 May 2017 19:59:22 -0400 X-Originating-IP: 72.66.113.207 Subject: Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN To: Daniel Micay , Nick Kralevich , Stephen Smalley , Alan Cox , Kees Cook 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> <100b7d8c-7468-3122-4f59-3b0dcdf5dfc3@nmatt.com> <1496175757.9871.6.camel@gmail.com> <99069e11-dc84-8198-5d1c-f39b18ac9971@nmatt.com> <1496187633.17013.2.camel@gmail.com> Cc: Casey Schaufler , Boris Lukashev , Greg KH , "Serge E. Hallyn" , kernel-hardening@lists.openwall.com, linux-security-module , linux-kernel From: Matt Brown Message-ID: <65b09473-a96a-69cf-9e5d-4a7d7e763da0@nmatt.com> Date: Tue, 30 May 2017 19:59:12 -0400 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <1496187633.17013.2.camel@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 5/30/17 7:40 PM, Daniel Micay wrote: > On Tue, 2017-05-30 at 19:00 -0400, Matt Brown wrote: >> On 5/30/17 4:22 PM, Daniel Micay wrote: >>>> Thanks, I didn't know that android was doing this. I still think >>>> this >>>> feature >>>> is worthwhile for people to be able to harden their systems >>>> against >>>> this attack >>>> vector without having to implement a MAC. >>> >>> Since there's a capable LSM hook for ioctl already, it means it >>> could go >>> in Yama with ptrace_scope but core kernel code would still need to >>> be >>> changed to track the owning tty. I think Yama vs. core kernel >>> shouldn't >>> matter much anymore due to stackable LSMs. >>> >> >> What does everyone think about a v8 that moves this feature under Yama >> and uses >> the file_ioctl LSM hook? > > It would only make a difference if it could be fully contained there, as > in not depending on tracking the tty owner. > For the reasons discussed earlier (to allow for nested containers where one of the containers is privileged) we want to track the user namespace that owns the tty.