Quoting Matt Brown (matt@xxxxxxxxx): > 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. -serge -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
