[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAGXu5jLuqApE_yLNwHDZYfE7ujM2hVSr1dd_WHPfREPUiEwE-Q@mail.gmail.com>
Date: Fri, 2 Jun 2017 12:25:25 -0700
From: Kees Cook <keescook@...omium.org>
To: Matt Brown <matt@...tt.com>
Cc: "Serge E. Hallyn" <serge@...lyn.com>, Alan Cox <gnomes@...rguk.ukuu.org.uk>,
Casey Schaufler <casey@...aufler-ca.com>, Boris Lukashev <blukashev@...pervictus.com>,
Greg KH <gregkh@...uxfoundation.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>, Linux API <linux-api@...r.kernel.org>
Subject: Re: Re: [PATCH v7 2/2] security: tty: make TIOCSTI
ioctl require CAP_SYS_ADMIN
On Fri, Jun 2, 2017 at 12:22 PM, Matt Brown <matt@...tt.com> wrote:
> On 6/2/17 2:18 PM, Serge E. Hallyn wrote:
>> Quoting Matt Brown (matt@...tt.com):
>>> On 6/2/17 12:57 PM, Serge E. Hallyn wrote:
>>>> I'm not quite sure what you're asking for here. Let me offer a precise
>>>> strawman design. I'm sure there are problems with it, it's just a starting
>>>> point.
>>>>
>>>> system-wide whitelist (for now 'may_push_chars') is full by default.
>>>>
>>>
>>> So is may_push_chars just an alias for TIOCSTI? Or are there some
>>> potential whitelist members that would map to multiple ioctls?
>>
>> <shrug> I'm seeing it as only TIOCSTI right now.
>>
>>>> By default, nothing changes - you can use those on your own tty, need
>>>> CAP_SYS_ADMIN against init_user_ns otherwise.
>>>>
>>>> Introduce a new CAP_TTY_PRIVILEGED.
>>>>
>>>
>>> I'm fine with this.
>>>
>>>> When may_push_chars is removed from the whitelist, you lose the ability
>>>> to use TIOCSTI on a tty - even your own - if you do not have CAP_TTY_PRIVILEGED
>>>> against the tty's user_ns.
>>>>
>>>
>>> How do you propose storing/updating the whitelist? sysctl?
>>>
>>> If it is a sysctl, would each whitelist member have a sysctl?
>>> e.g.: kernel.ioctlwhitelist.may_push_chars = 1
>>>
>>> Overall, I'm fine with this idea.
>>
>> That sounds reasonable. Or a securityfs file - I guess not everyone
>> has securityfs, but if it were to become part of YAMA then that would
>> work.
>>
>
> Yama doesn't depend on securityfs does it?
>
> What do other people think? Should this be an addition to YAMA or its
> own thing?
>
> Alan Cox: what do you think of the above ioctl whitelisting scheme?
It's easy to stack LSMs, so since Yama is ptrace-focused, perhaps make
a separate one for TTY hardening?
-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.
