From: Alan Cox <gnomes@lxorguk.ukuu.org.uk>
To: Kees Cook <keescook@chromium.org>
Cc: Matt Brown <matt@nmatt.com>,
Casey Schaufler <casey@schaufler-ca.com>,
Boris Lukashev <blukashev@sempervictus.com>,
Greg KH <gregkh@linuxfoundation.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
"kernel-hardening@lists.openwall.com"
<kernel-hardening@lists.openwall.com>,
linux-security-module <linux-security-module@vger.kernel.org>,
linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: [kernel-hardening] Re: [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN
Date: Thu, 1 Jun 2017 14:08:12 +0100 [thread overview]
Message-ID: <20170601140812.583cf0a5@alans-desktop> (raw)
In-Reply-To: <CAGXu5j+pqD1082fYDS_dvDB2QNvt9wSz+C7vAhGpMXcJWxoDkw@mail.gmail.com>
> I still cannot wrap my head around why providing users with a
> protection is a bad thing. Yes, the other tty games are bad, but this
> fixes a specific and especially bad case that is easy to kill. It's
> got a Kconfig and a sysctl. It's not on by default. This protects the
> common case of privileged ttys that aren't attached to consoles, etc,
Which just leads to stuff not getting fixed. Like all the code out there
today which is still vulnerable to selection based attacks because people
didn't do the job right when "fixing" stuff because they are not
thinking about security at a systems level but just tickboxing CVEs.
I'm not against doing something to protect the container folks, but that
something as with Android is a whitelist of ioctls. And if we need to do
this with a kernel hook lets do it properly.
Remember the namespace of the tty on creation
If the magic security flag is set then
Apply a whitelist to *any* tty ioctl call where the ns doesn't
match
and we might as well just take the Android whitelist since they've kindly
built it for us all!
In the tty layer it ends up being something around 10 lines of code and
some other file somewhere in security/ that's just a switch or similar
with the whitelisted ioctl codes in it.
That (or a similar SELinux ruleset) would actually fix the problem.
SELinux would be better because it can also apply the rules when doing
things like su/sudo/...
Alan
next prev parent reply other threads:[~2017-06-01 13:08 UTC|newest]
Thread overview: 49+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-29 21:37 [PATCH v7 0/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown
2017-05-29 21:37 ` [PATCH v7 1/2] security: tty: Add owner user namespace to tty_struct Matt Brown
2017-05-29 21:38 ` [PATCH v7 2/2] security: tty: make TIOCSTI ioctl require CAP_SYS_ADMIN Matt Brown
2017-05-29 22:26 ` Alan Cox
2017-05-29 23:51 ` [kernel-hardening] " Boris Lukashev
2017-05-30 0:27 ` Casey Schaufler
2017-05-30 2:00 ` Matt Brown
2017-05-30 2:46 ` Casey Schaufler
2017-05-30 3:18 ` Matt Brown
2017-05-30 12:24 ` Alan Cox
2017-05-30 16:28 ` Matt Brown
2017-05-30 16:44 ` Daniel Micay
2017-05-30 18:32 ` Stephen Smalley
2017-05-30 18:44 ` Nick Kralevich
2017-05-30 18:57 ` Matt Brown
2017-05-30 20:22 ` Daniel Micay
2017-05-30 23:00 ` Matt Brown
2017-05-30 23:40 ` Daniel Micay
2017-05-30 23:59 ` Matt Brown
2017-05-30 22:51 ` Alan Cox
2017-05-30 23:19 ` Matt Brown
2017-05-30 23:56 ` Alan Cox
2017-06-01 2:35 ` Kees Cook
2017-06-01 13:08 ` Alan Cox [this message]
2017-06-01 17:18 ` Serge E. Hallyn
2017-06-01 21:26 ` Alan Cox
2017-06-01 18:58 ` Kees Cook
2017-06-01 21:24 ` Alan Cox
2017-06-02 14:46 ` Matt Brown
2017-06-02 15:36 ` Serge E. Hallyn
2017-06-02 16:02 ` Matt Brown
2017-06-02 16:57 ` Serge E. Hallyn
2017-06-02 17:32 ` Matt Brown
2017-06-02 18:18 ` Serge E. Hallyn
2017-06-02 19:22 ` Matt Brown
2017-06-02 19:25 ` Kees Cook
2017-06-02 19:26 ` Matt Brown
2017-06-02 20:05 ` Alan Cox
2017-06-02 20:11 ` Nick Kralevich
2017-06-02 20:46 ` Matt Brown
2017-06-03 22:00 ` Alan Cox
2017-06-03 22:22 ` Matt Brown
2017-06-04 3:37 ` Peter Dolding
2017-05-30 15:20 ` Casey Schaufler
2017-05-30 16:09 ` Matt Brown
2017-06-04 6:29 ` Boris Lukashev
2017-05-31 2:48 ` James Morris
2017-05-31 4:10 ` Matt Brown
2017-05-30 0:15 ` Matt Brown
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170601140812.583cf0a5@alans-desktop \
--to=gnomes@lxorguk.ukuu.org.uk \
--cc=blukashev@sempervictus.com \
--cc=casey@schaufler-ca.com \
--cc=gregkh@linuxfoundation.org \
--cc=keescook@chromium.org \
--cc=kernel-hardening@lists.openwall.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matt@nmatt.com \
--cc=serge@hallyn.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).