LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: James Morris <jmorris@namei.org>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Andy Lutomirski <luto@kernel.org>,
	Matthew Garrett <mjg59@google.com>,
	LSM List <linux-security-module@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [RFC] Turn lockdown into an LSM
Date: Thu, 23 May 2019 05:19:15 +1000 (AEST)	[thread overview]
Message-ID: <alpine.LRH.2.21.1905230457000.18826@namei.org> (raw)
In-Reply-To: <14ed1f30-a1d0-f973-5c8c-241337c8fc09@tycho.nsa.gov>

On Wed, 22 May 2019, Stephen Smalley wrote:

> That seems to violate the intent of lockdown as I understood it, and 
> turns security_is_locked_down() into a finer-grained capable() call. 
> Also, if I understand correctly, this could only be done if one were to 
> disable the lockdown module in the lsm list, since the security 
> framework will return non-zero (i.e. the operation is locked down) if 
> any module that implements the hook returns non-zero; LSM is 
> "restrictive". At that point SELinux or the other LSM would be the sole 
> arbiter of lockdown decisions. SELinux or the other LSM also wouldn't 
> have access to the kernel_locked_down level unless that was exported in 
> some manner from the lockdown module.  Not sure how to compose these.

Right, I was envisaging the LSM replacing the default.

i.e. the default is tristate OR fine grained LSM policy.

They could in theory be composed restrictively, but this is likely not 
useful given the coarse grained default policy.  All the LSM could do is 
either further restrict none or integrity.

We'd need to figure out how to avoid confusing users in the case where 
multiple LSMs are registered for the hooks, possibly by having the 
lockdown LSM gate this and update the securityfs lockdown node with 
something like "lsm:smack".


-- 
James Morris
<jmorris@namei.org>


  reply	other threads:[~2019-05-22 19:19 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
2019-05-22 18:30       ` Stephen Smalley
2019-05-22 19:19         ` James Morris [this message]
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:
  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.1905230457000.18826@namei.org \
    --to=jmorris@namei.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=luto@kernel.org \
    --cc=mjg59@google.com \
    --cc=sds@tycho.nsa.gov \
    --subject='Re: [RFC] Turn lockdown into an LSM' \
    /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

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