[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <de387727-680e-7563-ff5b-17c3ea742e62@digikod.net>
Date: Thu, 16 Aug 2018 21:45:27 +0200
From: Mickaël Salaün <mic@...ikod.net>
To: Kees Cook <keescook@...omium.org>,
Casey Schaufler <casey@...aufler-ca.com>
Cc: Jordan Glover <Golden_Miller83@...tonmail.ch>,
Sargun Dhillon <sargun@...gun.me>,
LSM <linux-security-module@...r.kernel.org>,
LKLM <linux-kernel@...r.kernel.org>,
Paul Moore <paul@...l-moore.com>,
Stephen Smalley <sds@...ho.nsa.gov>,
SE Linux <selinux@...ho.nsa.gov>,
"SMACK-discuss@...ts.01.org" <SMACK-discuss@...ts.01.org>,
John Johansen <john.johansen@...onical.com>,
Tetsuo Handa <penguin-kernel@...ove.sakura.ne.jp>,
James Morris <jmorris@...ei.org>,
"Schaufler, Casey" <casey.schaufler@...el.com>,
Salvatore Mesoraca <s.mesoraca16@...il.com>
Subject: Re: [PATCH v1 00/22] LSM: Full security module stacking
On 08/15/2018 07:19 AM, Kees Cook wrote:
> On Tue, Aug 14, 2018 at 4:50 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>> On 8/14/2018 4:22 PM, Jordan Glover wrote:
>>> On August 14, 2018 8:28 PM, Casey Schaufler <casey@...aufler-ca.com> wrote:
>>>
>>>>
>>>>>> The blob management part (through "LSM: Sharing of security blobs")
>>>>>> is ready for prime-time. These changes move the management of
>>>>>> security blobs out of the security modules and into the security
>>>>>> module infrastructure. With this change the proposed S.A.R.A,
>>>>>> LandLock and PTAGS security modules could co-exist with any of
>>>>>> the existing "major" security modules. The changes reduce some
>>>>>> code duplication.
>>>>>> Beyond the blob management there's a bit of clean-up.
>>>>>> Mounting filesystems had to be changed so that options
>>>>>> a security module doesn't recognize won't be considered
>>>>>> a fatal error. The mount infrastructure is somewhat
>>>>>> more complex than one might assume.
>>>>> Casey,
>>>>> Do you think you can break out 1 into its own patch? It seems like
>>>>> that'd be valuable to everyone.
>>>> Yes, I think that is a good idea. Landlock, S.A.R.A. and a couple
>>>> other security modules could be added upstream if this part of the
>>>> work was available. It would not provide everything needed to stack
>>>> all the existing modules. I believe there is concern that if this
>>>> much went upstream the work on finishing what's required to make
>>>> everything work might be abandoned.
>>>>
>>> On the other hand there is concern that those security modules might
>>> be abandoned if they have to wait until everything is finished :)
>>
>> There is some truth to that. If we can get commitment from the developers
>> of those security module to push for getting upstream, a statement of
>> intent to support additional modules (e.g. Landlock, S.A.R.A.) from a
I'm the developer of Landlock. I'm working on it on my free time but my
employer is also interested and I have some dedicated time for Landlock
at work too. I've been quite busy these past months but I'll get back on
Landlock soon.
As Salvatore said, my goal is also to get Landlock upstream. The current
code is quite mature compared to the first version but there is still
some work to do before the next patch series. BTW, code reviews are much
appreciated!
The LSM stacking patch series may not be a blocker for upstreaming
Landlock but this series is needed to enable Landlock on common distro
(which won't disable their current major LSM). It would be easier to
have the LSM stacking upstream as soon as possible though.
>> significant distribution (e.g. Fedora, Ubuntu, SuSE) and ACKs from the
>> maintainers of the existing modules we should be able to breeze right in.
>>
>> Yeah, I think that's about all it would take.
>
> I would strongly recommend Landlock and SARA for every distro. They're
> opt-in, and provide much-needed missing userspace defenses (and attack
> surface reduction).
>
> -Kees
>
Thanks Kees! And great work Casey!
Mickaël
Download attachment "signature.asc" of type "application/pgp-signature" (489 bytes)
Powered by blists - more mailing lists