On Fri, Jun 2, 2017 at 12:22 PM, Matt Brown [off-list ref] wrote:

On 6/2/17 2:18 PM, Serge E. Hallyn wrote:

quoted

Quoting Matt Brown (matt at nmatt.com):

quoted

On 6/2/17 12:57 PM, Serge E. Hallyn wrote:

quoted

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.

quoted

quoted

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.

quoted

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
--
To unsubscribe from this list: send the line "unsubscribe linux-security-module" in
the body of a message to majordomo at vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html