LKML Archive on
help / color / mirror / Atom feed
From: Andy Lutomirski <>
To: Matthew Garrett <>
Cc: James Morris <>,
	LSM List <>,
	Linux Kernel Mailing List <>,
	Andy Lutomirski <>
Subject: Re: [RFC] Turn lockdown into an LSM
Date: Wed, 22 May 2019 10:08:32 -0700	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, May 22, 2019 at 9:49 AM Matthew Garrett <> wrote:
> On Tue, May 21, 2019 at 7:40 PM James Morris <> wrote:
> > An LSM could also potentially implement its own policy for the hook.
> That was my plan. Right now the hook just gets an ASCII description of
> the reason for the lockdown - that seems suboptimal for cases like
> SELinux. What information would you want? My initial thinking was to
> just have a stable enum of lockdown reasons that's in the UAPI headers
> and then let other LSM tooling consume that, but I haven't spent
> enough time with the internals of SELinux to know if there'd be a more
> attractive solution.

I may be in the minority here, but I see this issue as a significant
downside of making lockdown more flexible.  If we stick with just
"this may violate integrity" and "this may violate confidentiality",
then the ABI surface is nice and narrow.  If we start having a big
uapi list of things that might qualify for lockdown, we need to worry
about compatibility issues.

This isn't purely theoretical.  Lockdown has some interesting
interactions with eBPF.  I don't want to be in a situation where v1 of
lockdown has a few eBPF hooks, but a later update improves the eBPF vs
lockdown interaction so that you can do more with eBPF on a locked
down kernel.  But now any such change has to worry about breaking the
lockdown LSM ABI.

And I still think it would be nice to have some credible use case for
a more fine grained policy than just the tri-state.  Having a lockdown
policy of "may not violate kernel confidentiality except using
kprobes" may be convenient, but it's also basically worthless, since
kernel confidentiality is gone.

All this being said, I do see one big benefit for LSM integration:
SELinux or another LSM could allow certain privileged tasks to bypass
lockdown.  This seems fine, except that there's potential nastiness
where current->cred isn't actually a valid thing to look at in the
current context.

So I guess my proposal is: use LSM, but make the hook very coarse
grained: int security_violate_confidentiality(const struct cred *) and
int security_violate_integrity(const struct cred *).


  reply	other threads:[~2019-05-22 17:08 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-05-21 22:40 Matthew Garrett
2019-05-21 22:40 ` [RFC 1/2] security: Support early LSMs Matthew Garrett
2019-05-21 22:40 ` [RFC 2/2] Add the ability to lock down access to the running kernel image Matthew Garrett
2019-05-22  2:48   ` James Morris
2019-05-22  2:40 ` [RFC] Turn lockdown into an LSM James Morris
2019-05-22 16:48   ` Matthew Garrett
2019-05-22 17:08     ` Andy Lutomirski [this message]
2019-05-22 18:05       ` James Morris
2019-05-22 18:30       ` Stephen Smalley
2019-05-22 19:19         ` James Morris
2019-05-22 19:57           ` Casey Schaufler
2019-05-22 20:03           ` Stephen Smalley

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='' \ \ \ \ \ \
    --subject='Re: [RFC] Turn lockdown into an LSM' \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

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).