From: Matt Brown <matt@nmatt.com>
To: Peter Dolding <oiaohm@gmail.com>, Kees Cook <keescook@chromium.org>
Cc: Alan Cox <gnomes@lxorguk.ukuu.org.uk>,
"Serge E. Hallyn" <serge@hallyn.com>,
Greg KH <gregkh@linuxfoundation.org>,
Jiri Slaby <jslaby@suse.com>,
Andrew Morton <akpm@linux-foundation.org>,
Jann Horn <jannh@google.com>, James Morris <jmorris@namei.org>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: [kernel-hardening] Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
Date: Tue, 16 May 2017 17:54:38 -0400 [thread overview]
Message-ID: <5e6b80da-8185-22f3-ff8c-b976ad743f5d@nmatt.com> (raw)
In-Reply-To: <CANA3KFX37=WEVXedSGAqMH_DxS=SxtjpeZ0PRizPQcBSyDqVpw@mail.gmail.com>
On 05/16/2017 05:43 PM, Peter Dolding wrote:
> On Wed, May 17, 2017 at 12:28 AM, Kees Cook <keescook@chromium.org> wrote:
>> On Tue, May 16, 2017 at 5:22 AM, Matt Brown <matt@nmatt.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).
>
> 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
next prev parent reply other threads:[~2017-05-16 21:54 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-05 23:20 [kernel-hardening] [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown
2017-05-05 23:20 ` [kernel-hardening] [PATCH v6 1/2] security: tty: Add owner user namespace to tty_struct Matt Brown
2017-05-05 23:20 ` [kernel-hardening] [PATCH v6 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown
2017-05-18 13:31 ` [kernel-hardening] " Greg KH
2017-05-19 4:51 ` Matt Brown
2017-05-10 20:29 ` [kernel-hardening] Re: [PATCH v6 0/2] " Alan Cox
2017-05-10 21:02 ` Daniel Micay
2017-05-13 19:52 ` Matt Brown
2017-05-15 4:45 ` Nicolas Belouin
2017-05-15 20:57 ` Alan Cox
2017-05-15 23:10 ` Peter Dolding
2017-05-16 4:15 ` Matt Brown
2017-05-16 9:01 ` Peter Dolding
2017-05-16 12:22 ` Matt Brown
2017-05-16 14:28 ` Kees Cook
2017-05-16 15:48 ` Serge E. Hallyn
2017-05-16 22:05 ` Peter Dolding
2017-05-16 21:43 ` Peter Dolding
2017-05-16 21:54 ` Matt Brown [this message]
2017-05-17 16:41 ` Alan Cox
2017-05-17 18:25 ` Daniel Micay
2017-05-17 23:04 ` Boris Lukashev
2017-05-18 3:18 ` Kees Cook
2017-05-19 2:48 ` Peter Dolding
2017-05-19 4:08 ` Boris Lukashev
2017-05-19 14:33 ` Serge E. Hallyn
2017-05-29 10:42 ` Peter Dolding
2017-05-30 15:52 ` Serge E. Hallyn
2017-05-30 21:52 ` Alan Cox
2017-05-31 11:27 ` Peter Dolding
2017-05-31 14:36 ` Alan Cox
2017-05-31 15:32 ` Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5e6b80da-8185-22f3-ff8c-b976ad743f5d@nmatt.com \
--to=matt@nmatt.com \
--cc=akpm@linux-foundation.org \
--cc=gnomes@lxorguk.ukuu.org.uk \
--cc=gregkh@linuxfoundation.org \
--cc=jannh@google.com \
--cc=jmorris@namei.org \
--cc=jslaby@suse.com \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=oiaohm@gmail.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).