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 07:28:52 -0700
From: Kees Cook <>
To: Matt Brown <>
Cc: Peter Dolding <>, 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 CAP_SYS_ADMIN

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

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