From: James Morris <jmorris@namei.org>
To: Andy Lutomirski <luto@kernel.org>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
Linux API <linux-api@vger.kernel.org>,
Matthew Garrett <matthewgarrett@google.com>,
LSM List <linux-security-module@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>,
David Howells <dhowells@redhat.com>,
Alexei Starovoitov <alexei.starovoitov@gmail.com>,
Network Development <netdev@vger.kernel.org>,
Chun-Yi Lee <jlee@suse.com>,
Daniel Borkmann <daniel@iogearbox.net>,
Kees Cook <keescook@chromium.org>, Will Drewry <wad@chromium.org>
Subject: Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down
Date: Thu, 28 Mar 2019 14:15:46 +1100 (AEDT) [thread overview]
Message-ID: <alpine.LRH.2.21.1903281403540.27561@namei.org> (raw)
In-Reply-To: <CALCETrUZ+oP0xxNt4mwN=AZA+zvkkfPZiAsFmAuqUD48pOHbBg@mail.gmail.com>
On Tue, 26 Mar 2019, Andy Lutomirski wrote:
> >
> > kernel_is_locked_down("ioperm")
> >
> > becomes
> >
> > kernel_is_locked_down(LOCKDOWN_IOPERM)
> >
> > and this function checks e.g.
> >
> > if (lockdown_polcy[id]) {
> > fail or warn;
> > }
> >
> > Thoughts?
>
> I'm concerned that this gives too much useless flexibility to
> administrators and user code in general. If you can break kernel
> integrity, you can break kernel integrity -- it shouldn't really
> matter *how* you break it.
OTOH, this seems like a combination of mechanism and policy. The 3 modes
are a help here, but I wonder if they may be too coarse grained still,
e.g. if someone wants to allow a specific mechanism according to their own
threat model and mitigations.
Secure boot gives you some assurance of the static state of the system at
boot time, and lockdown is certainly useful (with or without secure boot),
but it's not a complete solution to runtime kernel integrity protection by
any stretch of the imagination. I'm concerned about it being perceived as
such.
I'm not sure how to think about it architecturally and how it fits as such
in the mainline kernel.
--
James Morris
<jmorris@namei.org>
next prev parent reply other threads:[~2019-03-28 3:15 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20190325220954.29054-1-matthewgarrett@google.com>
[not found] ` <20190325220954.29054-24-matthewgarrett@google.com>
[not found] ` <20190325164221.5d8687bd@shemminger-XPS-13-9360>
2019-03-26 0:10 ` [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down Andy Lutomirski
2019-03-26 18:57 ` James Morris
2019-03-26 19:22 ` Andy Lutomirski
2019-03-28 3:15 ` James Morris [this message]
2019-03-28 18:07 ` Matthew Garrett
2019-03-28 19:23 ` James Morris
2019-03-28 20:08 ` Matthew Garrett
2019-03-26 20:19 ` Matthew Garrett
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=alpine.LRH.2.21.1903281403540.27561@namei.org \
--to=jmorris@namei.org \
--cc=alexei.starovoitov@gmail.com \
--cc=daniel@iogearbox.net \
--cc=dhowells@redhat.com \
--cc=jlee@suse.com \
--cc=keescook@chromium.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=luto@kernel.org \
--cc=matthewgarrett@google.com \
--cc=netdev@vger.kernel.org \
--cc=stephen@networkplumber.org \
--cc=wad@chromium.org \
/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