From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753509AbdEPVzv (ORCPT ); Tue, 16 May 2017 17:55:51 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:60762 "EHLO relay4-d.mail.gandi.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752950AbdEPVzr (ORCPT ); Tue, 16 May 2017 17:55:47 -0400 X-Originating-IP: 72.66.113.207 Subject: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN To: Peter Dolding , Kees Cook References: <20170505232018.28846-1-matt@nmatt.com> <20170510212920.7f6bc5e6@alans-desktop> <20170515215752.4e9f3826@alans-desktop> <5c5c9b06-d2ec-c2e5-3ea2-463f315428f6@nmatt.com> <1a1730f3-5378-1ce5-77a9-b9bc8cd5c90b@nmatt.com> Cc: Alan Cox , "Serge E. Hallyn" , Greg KH , Jiri Slaby , Andrew Morton , Jann Horn , James Morris , "kernel-hardening@lists.openwall.com" , linux-security-module , linux-kernel From: Matt Brown Message-ID: <5e6b80da-8185-22f3-ff8c-b976ad743f5d@nmatt.com> Date: Tue, 16 May 2017 17:54:38 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 05/16/2017 05:43 PM, Peter Dolding wrote: > On Wed, May 17, 2017 at 12:28 AM, Kees Cook wrote: >> On Tue, May 16, 2017 at 5:22 AM, Matt Brown wrote: >>> On 05/16/2017 05:01 AM, Peter Dolding wrote: >>>>> >>>>> >>>>> I could see a case being make for CAP_SYS_TTY_CONFIG. However I still >>>>> choose to do with CAP_SYS_ADMIN because it is already in use in the >>>>> TIOCSTI ioctl. >>>>> >>>> Matt Brown don't give me existing behaviour. CAP_SYS_ADMIN is >>>> overload. The documentation tells you that you are not to expand it >>>> and you openly admit you have. >>>> >>> >>> This is not true that I'm openly going against what the documentation >>> instructs. The part of the email chain where I show this got removed >>> somehow. Again I will refer to the capabilities man page that you >>> quoted. >>> >>> From http://man7.org/linux/man-pages/man7/capabilities.7.html >>> >>> "Don't choose CAP_SYS_ADMIN if you can possibly avoid it! >>> ... >>> The only new features that should be associated with CAP_SYS_ADMIN are >>> ones that closely match existing uses in that silo." >>> >>> My feature affects the TIOCSTI ioctl. The TIOCSTI ioctl already falls >>> under CAP_SYS_ADMIN, therefore I actually *am* following the >>> documentation. >> >> CAP_SYS_ADMIN is the right choice here, I agree with Matt: it is >> already in use for TIOCSTI. We can't trivially add new capabilities >> flags (see the various giant threads debating this, the most recently >> that I remember from the kernel lock-down series related to Secure >> Boot). > > We cannot just keep on expanding CAP_SYS_ADMIN either. >> >>>> I fact this usage of TIOCSTI I personally think should require two >>>> capabilities flags set. CAP_SYS_ADMIN section left as it is at this >>>> stage. With TIOSCTI stuck behind another capability. >>>> >>>> If you had added a new capability flag you could set file capabilities >>>> on any of the old applications depending on the now secured behaviour. >> >> If we're adjusting applications, they should be made to avoid TIOSCTI >> completely. This looks to me a lot like the symlink restrictions: yes, >> userspace should be fixed to the do the right thing, but why not >> provide support to userspace to avoid the problem entirely? >> > Kees I like but you have forgot the all important rule. The Linus > Rule. Existing applications must have a method work. > So modify applications binary is not way out of problem. > > Please note making CAP_SYS_ADMIN the only way to use TIOCSTI also > means setting CAP_SYS_ADMIN on all the existing applications to obey > the Linus Rule of not break userspace. So this is why the patch is > strictly no as this means elevating privilege of existing applications > and possibly opening up more security flaws. This feature is not required so it is not "making CAP_SYS_ADMIN the only way to use TIOCSTI". It defaults to no as to not break some existing programs that use it. > > Reality any patch like the one we are talking about due to the Linus > Rule and the security risk it will open up obey this it just be > rejected. There is another kind of way I will cover with Serge. > > Peter Dolding. > Matt