linux-kernel - Re: [PATCH v30 03/12] landlock: Set up the security framework and manage credentials

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <3a8a9744-20fe-a3e7-24bb-aeac2c4b74f8@digikod.net>
Date:   Fri, 19 Mar 2021 20:07:55 +0100
From:   Mickaël Salaün <mic@...ikod.net>
To:     Kees Cook <keescook@...omium.org>
Cc:     James Morris <jmorris@...ei.org>, Jann Horn <jannh@...gle.com>,
        "Serge E . Hallyn" <serge@...lyn.com>,
        Al Viro <viro@...iv.linux.org.uk>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Andy Lutomirski <luto@...capital.net>,
        Anton Ivanov <anton.ivanov@...bridgegreys.com>,
        Arnd Bergmann <arnd@...db.de>,
        Casey Schaufler <casey@...aufler-ca.com>,
        David Howells <dhowells@...hat.com>,
        Jeff Dike <jdike@...toit.com>,
        Jonathan Corbet <corbet@....net>,
        Michael Kerrisk <mtk.manpages@...il.com>,
        Richard Weinberger <richard@....at>,
        Shuah Khan <shuah@...nel.org>,
        Vincent Dagonneau <vincent.dagonneau@....gouv.fr>,
        kernel-hardening@...ts.openwall.com, linux-api@...r.kernel.org,
        linux-arch@...r.kernel.org, linux-doc@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-kernel@...r.kernel.org,
        linux-kselftest@...r.kernel.org,
        linux-security-module@...r.kernel.org, x86@...nel.org,
        Mickaël Salaün <mic@...ux.microsoft.com>
Subject: Re: [PATCH v30 03/12] landlock: Set up the security framework and
 manage credentials


On 19/03/2021 19:45, Kees Cook wrote:
> On Tue, Mar 16, 2021 at 09:42:43PM +0100, Mickaël Salaün wrote:
>>  config LSM
>>  	string "Ordered list of enabled LSMs"
>> -	default "lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
>> -	default "lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
>> -	default "lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
>> -	default "lockdown,yama,loadpin,safesetid,integrity,bpf" if DEFAULT_SECURITY_DAC
>> -	default "lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
>> +	default "landlock,lockdown,yama,loadpin,safesetid,integrity,smack,selinux,tomoyo,apparmor,bpf" if DEFAULT_SECURITY_SMACK
>> +	default "landlock,lockdown,yama,loadpin,safesetid,integrity,apparmor,selinux,smack,tomoyo,bpf" if DEFAULT_SECURITY_APPARMOR
>> +	default "landlock,lockdown,yama,loadpin,safesetid,integrity,tomoyo,bpf" if DEFAULT_SECURITY_TOMOYO
>> +	default "landlock,lockdown,yama,loadpin,safesetid,integrity,bpf" if DEFAULT_SECURITY_DAC
>> +	default "landlock,lockdown,yama,loadpin,safesetid,integrity,selinux,smack,tomoyo,apparmor,bpf"
>>  	help
>>  	  A comma-separated list of LSMs, in initialization order.
>>  	  Any LSMs left off this list will be ignored. This can be
> 
> There was some discussion long ago about landlock needing to be last
> in the list because it was unprivileged. Is that no longer true? (And
> what is the justification for its position in the list?)

Indeed, I wanted to put Landlock last because it was an unprivileged
programmable access-control, which could lead to side-channel attacks
against other access-controls (e.g. to infer enforced policies). This is
not valid anymore because Landlock is not using eBPF, only the BPF LSM
does that (which is not the only reason why it is the last stacked).

> 
>> diff --git a/security/landlock/common.h b/security/landlock/common.h
>> new file mode 100644
>> index 000000000000..5dc0fe15707d
>> --- /dev/null
>> +++ b/security/landlock/common.h
>> @@ -0,0 +1,20 @@
>> +/* SPDX-License-Identifier: GPL-2.0-only */
>> +/*
>> + * Landlock LSM - Common constants and helpers
>> + *
>> + * Copyright © 2016-2020 Mickaël Salaün <mic@...ikod.net>
>> + * Copyright © 2018-2020 ANSSI
>> + */
>> +
>> +#ifndef _SECURITY_LANDLOCK_COMMON_H
>> +#define _SECURITY_LANDLOCK_COMMON_H
>> +
>> +#define LANDLOCK_NAME "landlock"
>> +
>> +#ifdef pr_fmt
>> +#undef pr_fmt
>> +#endif
> 
> When I see "#undef pr_fmt" I think there is a header ordering problem.

Not is this case, it's a "namespace" definition. :)

> 
>> [...]
> 
> Everything else looks like regular boilerplate for an LSM. :)
> 
> Reviewed-by: Kees Cook <keescook@...omium.org>
>