Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 16 May 2017 17:54:38 -0400
From: Matt Brown <>
To: Peter Dolding <>, Kees Cook <>
Cc: Alan Cox <>, "Serge E. Hallyn"
 <>, Greg KH <>,
 Jiri Slaby <>, Andrew Morton <>,
 Jann Horn <>, James Morris <>,
 "" <>,
 linux-security-module <>,
 linux-kernel <>
Subject: Re: [PATCH v6 0/2] security: tty: make TIOCSTI ioctl require

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
>>> "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.


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.