Date: Tue, 16 May 2017 07:28:52 -0700 From: Kees Cook <keescook@...omium.org> To: Matt Brown <matt@...tt.com> Cc: Peter Dolding <oiaohm@...il.com>, Alan Cox <gnomes@...rguk.ukuu.org.uk>, "Serge E. Hallyn" <serge@...lyn.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: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN On Tue, May 16, 2017 at 5:22 AM, Matt Brown <matt@...tt.com> 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). >> 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 -- Kees Cook Pixel Security
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.