From: "Mickaël Salaün" <mic@digikod.net>
To: Kees Cook <keescook@chromium.org>,
Casey Schaufler <casey@schaufler-ca.com>
Cc: Jordan Glover <Golden_Miller83@protonmail.ch>,
Sargun Dhillon <sargun@sargun.me>,
LSM <linux-security-module@vger.kernel.org>,
LKLM <linux-kernel@vger.kernel.org>,
Paul Moore <paul@paul-moore.com>,
Stephen Smalley <sds@tycho.nsa.gov>,
SE Linux <selinux@tycho.nsa.gov>,
"SMACK-discuss@lists.01.org" <SMACK-discuss@lists.01.org>,
John Johansen <john.johansen@canonical.com>,
Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp>,
James Morris <jmorris@namei.org>,
"Schaufler, Casey" <casey.schaufler@intel.com>,
Salvatore Mesoraca <s.mesoraca16@gmail.com>
Subject: Re: [PATCH v1 00/22] LSM: Full security module stacking
Date: Thu, 16 Aug 2018 21:45:27 +0200 [thread overview]
Message-ID: <de387727-680e-7563-ff5b-17c3ea742e62@digikod.net> (raw)
In-Reply-To: <CAGXu5jJ6Ngv8A=3TV5z5+x5kCkkXwjYtDfSQjUQgscP4hv_xYg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 3128 bytes --]
On 08/15/2018 07:19 AM, Kees Cook wrote:
> On Tue, Aug 14, 2018 at 4:50 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
>> On 8/14/2018 4:22 PM, Jordan Glover wrote:
>>> On August 14, 2018 8:28 PM, Casey Schaufler <casey@schaufler-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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
next prev parent reply other threads:[~2018-08-16 19:55 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-07-16 17:53 Casey Schaufler
2018-07-16 18:22 ` [PATCH v1 01/22] procfs: add smack subdir to attrs Casey Schaufler
2018-07-16 18:22 ` [PATCH v1 02/22] Smack: Abstract use of cred security blob Casey Schaufler
2018-07-16 18:22 ` [PATCH v1 03/22] SELinux: " Casey Schaufler
2018-07-16 18:22 ` [PATCH v1 04/22] LSM: Infrastructure management of the " Casey Schaufler
2018-07-16 18:22 ` [PATCH v1 05/22] SELinux: Abstract use of file " Casey Schaufler
2018-07-16 18:22 ` [PATCH v1 06/22] LSM: Infrastructure management of the " Casey Schaufler
2018-07-16 18:23 ` [PATCH v1 07/22] LSM: Infrastructure management of the task " Casey Schaufler
2018-07-16 18:23 ` PATCH v1 08/22] SELinux: Abstract use of inode " Casey Schaufler
2018-07-16 18:23 ` [PATCH v1 09/22] Smack: " Casey Schaufler
2018-07-16 18:23 ` [PATCH v1 10/22] LSM: Infrastructure management of the inode security Casey Schaufler
2018-07-16 18:23 ` [PATCH v1 11/22] LSM: Infrastructure management of the superblock security blob Casey Schaufler
2018-07-16 18:23 ` [PATCH v1 12/22] LSM: Infrastructure management of the sock security Casey Schaufler
2018-07-16 18:23 ` [PATCH v1 13/22] LSM: Infrastructure management of the ipc security blob Casey Schaufler
2018-07-16 18:23 ` [PATCH v1 14/22] LSM: Infrastructure management of the key " Casey Schaufler
2018-07-16 18:24 ` [PATCH v1 15/22] LSM: Mark security blob allocation failures as unlikely Casey Schaufler
2018-07-16 18:24 ` [PATCH v1 16/22] LSM: Sharing of security blobs Casey Schaufler
2018-07-16 18:24 ` [PATCH v1 17/22] LSM: Allow mount options from multiple security modules Casey Schaufler
2018-07-16 18:24 ` [PATCH v1 18/22] LSM: Use multiple secids in security module interfaces Casey Schaufler
2018-07-16 18:24 ` [PATCH v1 19/22] LSM: Use multiple secids in LSM interfaces Casey Schaufler
2018-07-16 18:24 ` [PATCH v1 20/22] Move common usercopy into security_getpeersec_stream Casey Schaufler
[not found] ` <CGME20180803091011eucas1p29e46a12d1986f11e63547ea1ec8e8663@eucas1p2.samsung.com>
2018-08-03 9:10 ` Piotr Sawicki
2018-08-03 15:27 ` Casey Schaufler
2018-07-16 18:24 ` [PATCH v1 21/22] LSM: Multiple concurrent major security modules Casey Schaufler
[not found] ` <CGME20181009140944eucas1p1b935c2b8b2534cb15e36d28b7f9b134b@eucas1p1.samsung.com>
2018-10-09 14:09 ` Piotr Sawicki
2018-07-16 18:24 ` [PATCH v1 22/22] Netfilter: Add a selection for Smack Casey Schaufler
2018-07-16 18:28 ` [PATCH v1 00/22] LSM: Full security module stacking Casey Schaufler
2018-07-16 18:53 ` James Morris
2018-07-16 19:49 ` Casey Schaufler
2018-08-14 17:05 ` Sargun Dhillon
2018-08-14 18:28 ` Casey Schaufler
2018-08-14 23:22 ` Jordan Glover
2018-08-14 23:50 ` Casey Schaufler
2018-08-15 5:19 ` Kees Cook
2018-08-16 16:05 ` Salvatore Mesoraca
2018-08-16 19:45 ` Mickaël Salaün [this message]
2018-08-22 9:59 ` James Morris
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=de387727-680e-7563-ff5b-17c3ea742e62@digikod.net \
--to=mic@digikod.net \
--cc=Golden_Miller83@protonmail.ch \
--cc=SMACK-discuss@lists.01.org \
--cc=casey.schaufler@intel.com \
--cc=casey@schaufler-ca.com \
--cc=jmorris@namei.org \
--cc=john.johansen@canonical.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=paul@paul-moore.com \
--cc=penguin-kernel@i-love.sakura.ne.jp \
--cc=s.mesoraca16@gmail.com \
--cc=sargun@sargun.me \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®