Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Subject: Re: [RFC] Turn lockdown into an LSM
To:     James Morris <jmorris@namei.org>,
        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>
References: <20190521224013.3782-1-matthewgarrett@google.com>
 <alpine.LRH.2.21.1905221203070.3967@namei.org>
 <CACdnJuuTR=Ut4giPKC=kdxgY9yPv8+3PZyEzuxvON3Jr_92XnQ@mail.gmail.com>
 <CALCETrVow8U=xhQdJt8kSMX16Lf0Mstf3+QxY4iz4DHVp=PYWA@mail.gmail.com>
 <14ed1f30-a1d0-f973-5c8c-241337c8fc09@tycho.nsa.gov>
 <alpine.LRH.2.21.1905230457000.18826@namei.org>
From:   Casey Schaufler <casey@schaufler-ca.com>
Message-ID: <8b33a96f-160d-8e5d-4335-db2445cbe37a@schaufler-ca.com>
Date:   Wed, 22 May 2019 12:57:13 -0700
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101
 Thunderbird/60.7.0
MIME-Version: 1.0
In-Reply-To: <alpine.LRH.2.21.1905230457000.18826@namei.org>
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit
Content-Language: en-US
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On 5/22/2019 12:19 PM, James Morris wrote:
> 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".

The way I'd propose dealing with multiple LSMs using the
securityfs interface is the same as I'm proposing for
/proc/.../attr/current and SO_PEERSEC. A new interface
/proc/self/attr/display contains the name of the LSM that
the current process will see when looking at process or
security attributes that are "shared". Writing to display
is unprivileged and changes which LSM you get information
for.

Adornments like "lsm:smack" often require modification of
programs that fear change. The same would be true of a prctl().
The "display" file approach is no harder for applications that
are getting modified and much easier for scripts.