LKML Archive on
help / color / mirror / Atom feed
From: James Morris <>
To: Andy Lutomirski <>
Cc: Matthew Garrett <>,
	LSM List <>,
	Linux Kernel Mailing List <>
Subject: Re: [RFC] Turn lockdown into an LSM
Date: Thu, 23 May 2019 04:05:56 +1000 (AEST)	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Wed, 22 May 2019, Andy Lutomirski wrote:

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

This is an important point, but there's also "can't use any lockdown 
features because the admin might need to use kprobes".  I mention a 
use-case below.

I think it's fine (and probably preferred) to keep the default behavior 
tri-state and allow LSMs to implement finer-grained policies.

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

Some environments _need_ a "break glass" option, and a well-defined policy
(e.g. an SELinux domain which can only be entered via serial console, with
2FA or JIT credentials) to selectively un-lock the kernel lockdown in  
production would mean the difference between having a fleet of millions of
nodes 99.999% locked down vs 0%.

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


Can we identify any such cases in the current patchset?

One option would be for the LSM to assign a default (untrusted/unknown) 
value for the subject and then apply policy as needed (e.g. allow or deny 

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

Perhaps security_kernel_unlock_*

James Morris

  reply	other threads:[~2019-05-22 18:06 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
2019-05-22 18:05       ` James Morris [this message]
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 \ \ \ \ \ \ \
    --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).