From mboxrd@z Thu Jan 1 00:00:00 1970 From: matt@nmatt.com (Matt Brown) Date: Fri, 2 Jun 2017 15:26:53 -0400 Subject: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN In-Reply-To: References: <20170531005633.484a2e14@alans-desktop> <20170601140812.583cf0a5@alans-desktop> <20170601222432.6f593538@lxorguk.ukuu.org.uk> <2d0ad49c-886e-1caf-771a-d251957f614c@nmatt.com> <20170602153647.GA2688@mail.hallyn.com> <20170602165732.GA3614@mail.hallyn.com> <3027e4fa-5dc2-a52f-8699-9974cb4d4b6b@nmatt.com> <20170602181822.GA5125@mail.hallyn.com> <1de2da93-01f5-1e26-ba4e-7c28fd9859f4@nmatt.com> Message-ID: To: linux-security-module@vger.kernel.org List-Id: linux-security-module.vger.kernel.org On 6/2/17 3:25 PM, Kees Cook wrote: > On Fri, Jun 2, 2017 at 12:22 PM, Matt Brown wrote: >> On 6/2/17 2:18 PM, Serge E. Hallyn wrote: >>> Quoting Matt Brown (matt at 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? >>> >>> 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? > Sounds good. I also like the idea of them being separate. Matt Brown -- 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