[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1496175757.9871.6.camel@gmail.com>
Date: Tue, 30 May 2017 16:22:37 -0400
From: Daniel Micay <danielmicay@...il.com>
To: Matt Brown <matt@...tt.com>, Nick Kralevich <nnk@...gle.com>, Stephen
Smalley <sds@...ho.nsa.gov>
Cc: Alan Cox <gnomes@...rguk.ukuu.org.uk>, Casey Schaufler
<casey@...aufler-ca.com>, Boris Lukashev <blukashev@...pervictus.com>, Greg
KH <gregkh@...uxfoundation.org>, "Serge E. Hallyn" <serge@...lyn.com>, Kees
Cook <keescook@...omium.org>, kernel-hardening@...ts.openwall.com,
linux-security-module <linux-security-module@...r.kernel.org>, linux-kernel
<linux-kernel@...r.kernel.org>
Subject: Re: Re: [PATCH v7 2/2] security: tty: make
TIOCSTI ioctl require CAP_SYS_ADMIN
> Thanks, I didn't know that android was doing this. I still think this
> feature
> is worthwhile for people to be able to harden their systems against
> this attack
> vector without having to implement a MAC.
Since there's a capable LSM hook for ioctl already, it means it could go
in Yama with ptrace_scope but core kernel code would still need to be
changed to track the owning tty. I think Yama vs. core kernel shouldn't
matter much anymore due to stackable LSMs.
Not the case for perf_event_paranoid=3 where a) there's already a sysctl
exposed which would be unfortunate to duplicate, b) there isn't an LSM
hook yet (AFAIK).
The toggles for ptrace and perf events are more useful though since
they're very commonly used debugging features vs. this obscure, rarely
used ioctl that in practice no one will notice is missing. It's still
friendlier to have a toggle than a seccomp policy requiring a reboot to
get rid of it, or worse compiling it out of the kernel.
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.
