Messages in this thread | | | From | Kees Cook <> | Date | Fri, 2 Jun 2017 12:25:25 -0700 | Subject | Re: [kernel-hardening] 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@nmatt.com> wrote: > On 6/2/17 2:18 PM, Serge E. Hallyn wrote: >> Quoting Matt Brown (matt@nmatt.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
| |