* LoadPin old-api-denied
From: Martin Townsend @ 2019-03-29 17:26 UTC (permalink / raw)
To: LSM, keescook
Hi,
I'm seeing the following message when trying to load some backported
kernel modules:
Mar 29 16:24:09 mach-cw-rnet-ppm-1840 kernel: LoadPin: kernel-module
old-api-denied obj=<unknown> pid=340 cmdline="modprobe compat"
I have other kernel modules that were built out of tree and these load
fine, the only difference I can see is that they are loaded via
/etc/modules-load.d
I've read through the loadpin docs and it states that it will only
allow modules that are from the main root filesystem and that
filesystem is read-only. I've checked and both of these are true for
the failing module. I've read through the source code and there's a
comment above the code path that loadpin is taking where the file
pointer is NULL.
/* This handles the older init_module API that has a NULL file. */
if (!file) {
I'm not 100% sure what this means, but could it be that
modprobe/insmod are using this older init_module API? if so how can I
get around this, I need to manually insert these modules at an
appropriate time during boot?
Any help greatly appreciated,
Martin.
^ permalink raw reply
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA?
From: Igor Zhbanov @ 2019-03-29 12:50 UTC (permalink / raw)
To: Stephen Smalley, Mimi Zohar, Matthew Garrett, Kees Cook,
Casey Schaufler, Paul Moore, John Johansen
Cc: linux-integrity, Jann Horn, linux-security-module
In-Reply-To: <b5a89692-4c93-80b3-37e5-41265765cdc3@tycho.nsa.gov>
On 29.03.2019 15:28, Stephen Smalley wrote:
> On 3/29/19 6:59 AM, Mimi Zohar wrote:
>> [Cc'ing the LSM mailing list and others]
>>
>> On Fri, 2019-03-29 at 13:00 +0300, Igor Zhbanov wrote:
>>> Hi Mimi,On 28.03.2019 20:17, Mimi Zohar wrote:
>>
>>>> I just came across the grsecurity article on mprotect.[1]
>>>> Has anyone looked at it? Would it make sense to make it a minor LSM?
>>>>
>>>> [1]https://pax.grsecurity.net/docs/mprotect.txt
>>>
>>> Interesting article. It is almost exactly of what I wanted to be
>>> implemented.
>>>
>>> If this minor LSM would be stackable to allow combining with e.g. SELinux
>>> then why not.
>>
>> Stacking shouldn't be a problem. Other LSMs are already on the
>> mprotect hook. Let's hear what others think.
>
> SELinux already provides a set of controls over executable mappings;
> see selinux_mmap_file and selinux_file_mprotect. Other major security
> modules may do likewise but I can't speak to that. Is there some gap
> you are trying to address that isn't already covered, or are you just
> trying to provide such restrictions without requiring one of the
> major modules?
I want to be sure that no unsigned code page could be executed. So exploits
could only be of ROP kind and not being able to download any extra code
from their servers. That's why I found that disabling of anonymous executable
pages could be useful for that (as well as disabling of making executable
pages writable to modify already mapped code). In conjunction with IMA it
should guarantee that no untrusted code could be executed.
As for SELinux abilities I need to check what can it do and what can't. Don't
ready to comment on that now. Will check.
As for modular approach I think that having this feature separately is
beneficial for distros do not using SELinux.
^ permalink raw reply
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA?
From: Stephen Smalley @ 2019-03-29 12:28 UTC (permalink / raw)
To: Mimi Zohar, Igor Zhbanov, Matthew Garrett, Kees Cook,
Casey Schaufler, Paul Moore, John Johansen
Cc: linux-integrity, Jann Horn, linux-security-module
In-Reply-To: <1553857187.9420.49.camel@linux.ibm.com>
On 3/29/19 6:59 AM, Mimi Zohar wrote:
> [Cc'ing the LSM mailing list and others]
>
> On Fri, 2019-03-29 at 13:00 +0300, Igor Zhbanov wrote:
>> Hi Mimi,On 28.03.2019 20:17, Mimi Zohar wrote:
>
>>> I just came across the grsecurity article on mprotect.[1]
>>> Has anyone looked at it? Would it make sense to make it a minor LSM?
>>>
>>> [1]https://pax.grsecurity.net/docs/mprotect.txt
>>
>> Interesting article. It is almost exactly of what I wanted to be implemented.
>>
>> If this minor LSM would be stackable to allow combining with e.g. SELinux
>> then why not.
>
> Stacking shouldn't be a problem. Other LSMs are already on the
> mprotect hook. Let's hear what others think.
SELinux already provides a set of controls over executable mappings; see
selinux_mmap_file and selinux_file_mprotect. Other major security
modules may do likewise but I can't speak to that. Is there some gap you
are trying to address that isn't already covered, or are you just trying
to provide such restrictions without requiring one of the major modules?
^ permalink raw reply
* [GIT PULL] tpmdd fixes for Linux v5.1
From: Jarkko Sakkinen @ 2019-03-29 11:55 UTC (permalink / raw)
To: jmorris; +Cc: linux-kernel, linux-security-module, linux-integrity
Hi James,
These are critical fixes for v5.1. Contains also couple of new selftests for
v5.1 features (partial reads in /dev/tpm0). I hope these could still reach
the release. Thanks.
/Jarkko
The following changes since commit 8d93e952fba216cd0811247f6360d97e0465d5fc:
LSM: lsm_hooks.h: fix documentation format (2019-03-26 16:46:22 -0700)
are available in the Git repository at:
git://git.infradead.org/users/jjs/linux-tpmdd.git tags/tpmdd-next-20190329
for you to fetch changes up to ada14f61ed5e111523ace5553d152ca89883c0a4:
tpm: turn on TPM on suspend for TPM 1.x (2019-03-29 13:48:40 +0200)
----------------------------------------------------------------
tpmdd fixes for Linux v5.1
----------------------------------------------------------------
Jarkko Sakkinen (2):
KEYS: trusted: allow trusted.ko to initialize w/o a TPM
tpm: turn on TPM on suspend for TPM 1.x
Tadeusz Struk (3):
selftests/tpm2: Open tpm dev in unbuffered mode
selftests/tpm2: Extend tests to cover partial reads
tpm: fix an invalid condition in tpm_common_poll
Yue Haibing (1):
tpm: Fix the type of the return value in calc_tpm2_event_size()
ndesaulniers@google.com (1):
KEYS: trusted: fix -Wvarags warning
drivers/char/tpm/eventlog/tpm2.c | 4 +-
drivers/char/tpm/tpm-dev-common.c | 9 ++++-
drivers/char/tpm/tpm-interface.c | 14 +++----
include/keys/trusted.h | 2 +-
security/keys/trusted.c | 32 +++++++++++----
tools/testing/selftests/tpm2/tpm2.py | 5 ++-
tools/testing/selftests/tpm2/tpm2_tests.py | 63 ++++++++++++++++++++++++++++++
7 files changed, 108 insertions(+), 21 deletions(-)
^ permalink raw reply
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA?
From: Jordan Glover @ 2019-03-29 11:51 UTC (permalink / raw)
To: Mimi Zohar
Cc: Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler,
Stephen Smalley, Paul Moore, John Johansen, linux-integrity,
Jann Horn, linux-security-module
In-Reply-To: <1553857187.9420.49.camel@linux.ibm.com>
On Friday, March 29, 2019 10:59 AM, Mimi Zohar <zohar@linux.ibm.com> wrote:
> [Cc'ing the LSM mailing list and others]
>
> On Fri, 2019-03-29 at 13:00 +0300, Igor Zhbanov wrote:
>
> > Hi Mimi,On 28.03.2019 20:17, Mimi Zohar wrote:
>
> > > I just came across the grsecurity article on mprotect.[1]
> > > Has anyone looked at it? Would it make sense to make it a minor LSM?
> > > [1]https://pax.grsecurity.net/docs/mprotect.txt
> >
> > Interesting article. It is almost exactly of what I wanted to be implemented.
> > If this minor LSM would be stackable to allow combining with e.g. SELinux
> > then why not.
>
> Stacking shouldn't be a problem. Other LSMs are already on the
> mprotect hook. Let's hear what others think.
>
> Mimi
There is already minor LSM in progress: https://sara.smeso.it/en/latest/
Jordan
^ permalink raw reply
* Re: Should mprotect(..., PROT_EXEC) be checked by IMA?
From: Mimi Zohar @ 2019-03-29 10:59 UTC (permalink / raw)
To: Igor Zhbanov, Matthew Garrett, Kees Cook, Casey Schaufler,
Stephen Smalley, Paul Moore, John Johansen
Cc: linux-integrity, Jann Horn, linux-security-module
In-Reply-To: <92718382-8669-748f-10d8-02fa21225210@omprussia.ru>
[Cc'ing the LSM mailing list and others]
On Fri, 2019-03-29 at 13:00 +0300, Igor Zhbanov wrote:
> Hi Mimi,On 28.03.2019 20:17, Mimi Zohar wrote:
> > I just came across the grsecurity article on mprotect.[1]
> > Has anyone looked at it? Would it make sense to make it a minor LSM?
> >
> > [1]https://pax.grsecurity.net/docs/mprotect.txt
>
> Interesting article. It is almost exactly of what I wanted to be implemented.
>
> If this minor LSM would be stackable to allow combining with e.g. SELinux
> then why not.
Stacking shouldn't be a problem. Other LSMs are already on the
mprotect hook. Let's hear what others think.
Mimi
^ permalink raw reply
* Re: [PATCH] tpm: turn on TPM on suspend for TPM 1.x
From: Jarkko Sakkinen @ 2019-03-29 9:41 UTC (permalink / raw)
To: Domenico Andreoli
Cc: linux-integrity, linux-security-module, pauldzim, Peter Huewe,
Jason Gunthorpe, Arnd Bergmann, Greg Kroah-Hartman, open list
In-Reply-To: <20190328171926.4luwqofh67uwgt5e@dumbo>
On Thu, Mar 28, 2019 at 06:19:26PM +0100, Domenico Andreoli wrote:
> On Fri, Mar 22, 2019 at 12:51:20PM +0200, Jarkko Sakkinen wrote:
> > tpm_chip_start/stop() should be also called for TPM 1.x devices on
> > suspend. Add that functionality back. Do not lock the chip because
> > it is unnecessary as there are no multiple threads using it when
> > doing the suspend.
> >
> > Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()")
> > Reported-by: Paul Zimmerman <pauldzim@gmail.com>
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> > drivers/char/tpm/tpm-interface.c | 14 ++++++--------
> > 1 file changed, 6 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
> > index 83ece5639f86..ae1030c9b086 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -402,15 +402,13 @@ int tpm_pm_suspend(struct device *dev)
> > if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED)
> > return 0;
> >
> > - if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> > - mutex_lock(&chip->tpm_mutex);
> > - if (!tpm_chip_start(chip)) {
> > + if (!tpm_chip_start(chip)) {
> > + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> > tpm2_shutdown(chip, TPM2_SU_STATE);
> > - tpm_chip_stop(chip);
> > - }
> > - mutex_unlock(&chip->tpm_mutex);
> > - } else {
> > - rc = tpm1_pm_suspend(chip, tpm_suspend_pcr);
> > + else
> > + rc = tpm1_pm_suspend(chip, tpm_suspend_pcr);
> > +
> > + tpm_chip_stop(chip);
> > }
> >
> > return rc;
>
> Tested-by: Domenico Andreoli <domenico.andreoli@linux.com>
Thank you! I'll do a PR to James during the weekend.
/Jarkko
^ permalink raw reply
* Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: Matthew Garrett @ 2019-03-28 20:08 UTC (permalink / raw)
To: James Morris
Cc: Andy Lutomirski, Stephen Hemminger, Linux API, LSM List, LKML,
David Howells, Alexei Starovoitov, Network Development,
Chun-Yi Lee, Daniel Borkmann, Kees Cook, Will Drewry
In-Reply-To: <alpine.LRH.2.21.1903290621350.1769@namei.org>
On Thu, Mar 28, 2019 at 12:23 PM James Morris <jmorris@namei.org> wrote:
>
> On Thu, 28 Mar 2019, Matthew Garrett wrote:
>
> > On Wed, Mar 27, 2019 at 8:15 PM James Morris <jmorris@namei.org> wrote:
> > > OTOH, this seems like a combination of mechanism and policy. The 3 modes
> > > are a help here, but I wonder if they may be too coarse grained still,
> > > e.g. if someone wants to allow a specific mechanism according to their own
> > > threat model and mitigations.
> >
> > In general the interfaces blocked by these patches could also be
> > blocked with an LSM, and I'd guess that people with more fine-grained
> > requirements would probably take that approach.
>
> So... I have to ask, why not use LSM for this in the first place?
>
> Either with an existing module or perhaps a lockdown LSM?
Some of it isn't really achievable that way - for instance, enforcing
module or kexec signatures. We have other mechanisms that can be used
to enable that which could be done at the more fine-grained level, but
a design goal was to make it possible to automatically enable a full
set of integrity protections under specified circumstances.
^ permalink raw reply
* Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: James Morris @ 2019-03-28 19:23 UTC (permalink / raw)
To: Matthew Garrett
Cc: Andy Lutomirski, Stephen Hemminger, Linux API, LSM List, LKML,
David Howells, Alexei Starovoitov, Network Development,
Chun-Yi Lee, Daniel Borkmann, Kees Cook, Will Drewry
In-Reply-To: <CACdnJusbi1jB+G0wMcj43wNik9Fiv3QCc8v30ztrFWg5-P-0iQ@mail.gmail.com>
On Thu, 28 Mar 2019, Matthew Garrett wrote:
> On Wed, Mar 27, 2019 at 8:15 PM James Morris <jmorris@namei.org> wrote:
> > OTOH, this seems like a combination of mechanism and policy. The 3 modes
> > are a help here, but I wonder if they may be too coarse grained still,
> > e.g. if someone wants to allow a specific mechanism according to their own
> > threat model and mitigations.
>
> In general the interfaces blocked by these patches could also be
> blocked with an LSM, and I'd guess that people with more fine-grained
> requirements would probably take that approach.
So... I have to ask, why not use LSM for this in the first place?
Either with an existing module or perhaps a lockdown LSM?
>
> > Secure boot gives you some assurance of the static state of the system at
> > boot time, and lockdown is certainly useful (with or without secure boot),
> > but it's not a complete solution to runtime kernel integrity protection by
> > any stretch of the imagination. I'm concerned about it being perceived as
> > such.
>
> What do you think the functionality gaps are in terms of ensuring
> kernel integrity (other than kernel flaws that allow the restrictions
> to be bypassed)?
I don't know of any non-flaw gaps.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: Matthew Garrett @ 2019-03-28 18:07 UTC (permalink / raw)
To: James Morris
Cc: Andy Lutomirski, Stephen Hemminger, Linux API, LSM List, LKML,
David Howells, Alexei Starovoitov, Network Development,
Chun-Yi Lee, Daniel Borkmann, Kees Cook, Will Drewry
In-Reply-To: <alpine.LRH.2.21.1903281403540.27561@namei.org>
On Wed, Mar 27, 2019 at 8:15 PM James Morris <jmorris@namei.org> wrote:
> OTOH, this seems like a combination of mechanism and policy. The 3 modes
> are a help here, but I wonder if they may be too coarse grained still,
> e.g. if someone wants to allow a specific mechanism according to their own
> threat model and mitigations.
In general the interfaces blocked by these patches could also be
blocked with an LSM, and I'd guess that people with more fine-grained
requirements would probably take that approach.
> Secure boot gives you some assurance of the static state of the system at
> boot time, and lockdown is certainly useful (with or without secure boot),
> but it's not a complete solution to runtime kernel integrity protection by
> any stretch of the imagination. I'm concerned about it being perceived as
> such.
What do you think the functionality gaps are in terms of ensuring
kernel integrity (other than kernel flaws that allow the restrictions
to be bypassed)?
^ permalink raw reply
* Re: [PATCH] tpm: turn on TPM on suspend for TPM 1.x
From: Domenico Andreoli @ 2019-03-28 17:19 UTC (permalink / raw)
To: Jarkko Sakkinen
Cc: linux-integrity, linux-security-module, pauldzim, Peter Huewe,
Jason Gunthorpe, Arnd Bergmann, Greg Kroah-Hartman, open list
In-Reply-To: <20190322105120.8441-1-jarkko.sakkinen@linux.intel.com>
On Fri, Mar 22, 2019 at 12:51:20PM +0200, Jarkko Sakkinen wrote:
> tpm_chip_start/stop() should be also called for TPM 1.x devices on
> suspend. Add that functionality back. Do not lock the chip because
> it is unnecessary as there are no multiple threads using it when
> doing the suspend.
>
> Fixes: a3fbfae82b4c ("tpm: take TPM chip power gating out of tpm_transmit()")
> Reported-by: Paul Zimmerman <pauldzim@gmail.com>
> Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> ---
> drivers/char/tpm/tpm-interface.c | 14 ++++++--------
> 1 file changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/char/tpm/tpm-interface.c b/drivers/char/tpm/tpm-interface.c
> index 83ece5639f86..ae1030c9b086 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -402,15 +402,13 @@ int tpm_pm_suspend(struct device *dev)
> if (chip->flags & TPM_CHIP_FLAG_ALWAYS_POWERED)
> return 0;
>
> - if (chip->flags & TPM_CHIP_FLAG_TPM2) {
> - mutex_lock(&chip->tpm_mutex);
> - if (!tpm_chip_start(chip)) {
> + if (!tpm_chip_start(chip)) {
> + if (chip->flags & TPM_CHIP_FLAG_TPM2)
> tpm2_shutdown(chip, TPM2_SU_STATE);
> - tpm_chip_stop(chip);
> - }
> - mutex_unlock(&chip->tpm_mutex);
> - } else {
> - rc = tpm1_pm_suspend(chip, tpm_suspend_pcr);
> + else
> + rc = tpm1_pm_suspend(chip, tpm_suspend_pcr);
> +
> + tpm_chip_stop(chip);
> }
>
> return rc;
Tested-by: Domenico Andreoli <domenico.andreoli@linux.com>
--
3B10 0CA1 8674 ACBA B4FE FCD2 CE5B CF17 9960 DE13
^ permalink raw reply
* Re: [PATCH v3] KEYS: trusted: allow trusted.ko to initialize w/o a TPM
From: Jarkko Sakkinen @ 2019-03-28 12:27 UTC (permalink / raw)
To: Dan Williams
Cc: linux-integrity, linux-security-module, James Morris,
James Bottomley, Mimi Zohar, David Howells, Serge E. Hallyn,
open list:KEYS-TRUSTED, open list
In-Reply-To: <CAA9_cmfFpkBLz6TU0sLSV1JYE43sDtfi29Xw4R5Xt-RaWm8ZLA@mail.gmail.com>
On Wed, Mar 27, 2019 at 10:15:50AM -0700, Dan Williams wrote:
> On Tue, Mar 26, 2019 at 5:13 AM Jarkko Sakkinen
> <jarkko.sakkinen@linux.intel.com> wrote:
> >
> > Allow trusted.ko to initialize w/o a TPM. This commit adds checks to the
> > key type callbacks and exported functions to fail when a TPM is not
> > available.
> >
> > Cc: James Morris <jmorris@namei.org>
> > Reported-by: Dan Williams <dan.j.williams@intel.com>
> > Tested-by: Dan Williams <dan.j.williams@intel.com>
> > Fixes: 240730437deb ("KEYS: trusted: explicitly use tpm_chip structure...")
> > Signed-off-by: Jarkko Sakkinen <jarkko.sakkinen@linux.intel.com>
> > ---
> > v3:
> > - remove unnecessary check for chip in init_trusted()
>
> v3 also tests ok here.
Thank you.
/Jarkko
^ permalink raw reply
* Re: [PATCH AUTOSEL 5.0 010/262] apparmor: fix double free when unpack of secmark rules fails
From: Pavel Machek @ 2019-03-28 10:08 UTC (permalink / raw)
To: Sasha Levin; +Cc: linux-kernel, stable, John Johansen, linux-security-module
In-Reply-To: <20190327180158.10245-10-sashal@kernel.org>
> From: John Johansen <john.johansen@canonical.com>
>
> [ Upstream commit d8dbb581d4f86a2ac669c056fc71a28ebeb367f4 ]
>
> if secmark rules fail to unpack a double free happens resulting in
> the following oops
>
> Fixes: 9caafbe2b4cf ("apparmor: Parse secmark policy")
> Reported-by: Alex Murray <alex.murray@canonical.com>
> Signed-off-by: John Johansen <john.johansen@canonical.com>
> Signed-off-by: Sasha Levin <sashal@kernel.org>
Acked-for-stable: Pavel Machek <pavel@ucw.cz>
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply
* Re: [PATCH 23/27] bpf: Restrict kernel image access functions when the kernel is locked down
From: James Morris @ 2019-03-28 3:15 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Stephen Hemminger, Linux API, Matthew Garrett, LSM List, LKML,
David Howells, Alexei Starovoitov, Network Development,
Chun-Yi Lee, Daniel Borkmann, Kees Cook, Will Drewry
In-Reply-To: <CALCETrUZ+oP0xxNt4mwN=AZA+zvkkfPZiAsFmAuqUD48pOHbBg@mail.gmail.com>
On Tue, 26 Mar 2019, Andy Lutomirski wrote:
> >
> > kernel_is_locked_down("ioperm")
> >
> > becomes
> >
> > kernel_is_locked_down(LOCKDOWN_IOPERM)
> >
> > and this function checks e.g.
> >
> > if (lockdown_polcy[id]) {
> > fail or warn;
> > }
> >
> > Thoughts?
>
> I'm concerned that this gives too much useless flexibility to
> administrators and user code in general. If you can break kernel
> integrity, you can break kernel integrity -- it shouldn't really
> matter *how* you break it.
OTOH, this seems like a combination of mechanism and policy. The 3 modes
are a help here, but I wonder if they may be too coarse grained still,
e.g. if someone wants to allow a specific mechanism according to their own
threat model and mitigations.
Secure boot gives you some assurance of the static state of the system at
boot time, and lockdown is certainly useful (with or without secure boot),
but it's not a complete solution to runtime kernel integrity protection by
any stretch of the imagination. I'm concerned about it being perceived as
such.
I'm not sure how to think about it architecturally and how it fits as such
in the mainline kernel.
--
James Morris
<jmorris@namei.org>
^ permalink raw reply
* [RFC PATCH 40/68] vfs: Convert smackfs to use the new mount API
From: David Howells @ 2019-03-27 23:45 UTC (permalink / raw)
To: viro
Cc: Casey Schaufler, linux-security-module, linux-fsdevel,
linux-kernel, dhowells
In-Reply-To: <155372999953.7602.13784796495137723805.stgit@warthog.procyon.org.uk>
Convert the smackfs filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Casey Schaufler <casey@schaufler-ca.com>
cc: linux-security-module@vger.kernel.org
---
security/smack/smackfs.c | 34 ++++++++++++++++++++++------------
1 file changed, 22 insertions(+), 12 deletions(-)
diff --git a/security/smack/smackfs.c b/security/smack/smackfs.c
index faf2ea3968b3..7e3a81d05136 100644
--- a/security/smack/smackfs.c
+++ b/security/smack/smackfs.c
@@ -27,6 +27,7 @@
#include <linux/ctype.h>
#include <linux/audit.h>
#include <linux/magic.h>
+#include <linux/fs_context.h>
#include "smack.h"
#define BEBITS (sizeof(__be32) * 8)
@@ -2843,14 +2844,13 @@ static const struct file_operations smk_ptrace_ops = {
/**
* smk_fill_super - fill the smackfs superblock
* @sb: the empty superblock
- * @data: unused
- * @silent: unused
+ * @fc: unused
*
* Fill in the well known entries for the smack filesystem
*
* Returns 0 on success, an error code on failure
*/
-static int smk_fill_super(struct super_block *sb, void *data, int silent)
+static int smk_fill_super(struct super_block *sb, struct fs_context *fc)
{
int rc;
@@ -2920,25 +2920,35 @@ static int smk_fill_super(struct super_block *sb, void *data, int silent)
}
/**
- * smk_mount - get the smackfs superblock
- * @fs_type: passed along without comment
- * @flags: passed along without comment
- * @dev_name: passed along without comment
- * @data: passed along without comment
+ * smk_get_tree - get the smackfs superblock
+ * @fc: The mount context, including any options
*
* Just passes everything along.
*
* Returns what the lower level code does.
*/
-static struct dentry *smk_mount(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
+static int smk_get_tree(struct fs_context *fc)
{
- return mount_single(fs_type, flags, data, smk_fill_super);
+ return vfs_get_super(fc, vfs_get_single_super, smk_fill_super);
+}
+
+static const struct fs_context_operations smk_context_ops = {
+ .get_tree = smk_get_tree,
+};
+
+/**
+ * smk_init_fs_context - Initialise a filesystem context for smackfs
+ * @fc: The blank mount context
+ */
+static int smk_init_fs_context(struct fs_context *fc)
+{
+ fc->ops = &smk_context_ops;
+ return 0;
}
static struct file_system_type smk_fs_type = {
.name = "smackfs",
- .mount = smk_mount,
+ .init_fs_context = smk_init_fs_context,
.kill_sb = kill_litter_super,
};
^ permalink raw reply related
* [RFC PATCH 39/68] vfs: Convert selinuxfs to use the new mount API
From: David Howells @ 2019-03-27 23:45 UTC (permalink / raw)
To: viro
Cc: Paul Moore, Stephen Smalley, Eric Paris, selinux,
linux-security-module, linux-fsdevel, linux-kernel, dhowells
In-Reply-To: <155372999953.7602.13784796495137723805.stgit@warthog.procyon.org.uk>
Convert the selinuxfs filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: Paul Moore <paul@paul-moore.com>
cc: Stephen Smalley <sds@tycho.nsa.gov>
cc: Eric Paris <eparis@parisplace.org>
cc: selinux@vger.kernel.org
cc: linux-security-module@vger.kernel.org
---
security/selinux/selinuxfs.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/security/selinux/selinuxfs.c b/security/selinux/selinuxfs.c
index 145ee62f205a..ccfe86dfa784 100644
--- a/security/selinux/selinuxfs.c
+++ b/security/selinux/selinuxfs.c
@@ -19,6 +19,7 @@
#include <linux/slab.h>
#include <linux/vmalloc.h>
#include <linux/fs.h>
+#include <linux/fs_context.h>
#include <linux/mount.h>
#include <linux/mutex.h>
#include <linux/init.h>
@@ -1893,7 +1894,7 @@ static struct dentry *sel_make_dir(struct dentry *dir, const char *name,
#define NULL_FILE_NAME "null"
-static int sel_fill_super(struct super_block *sb, void *data, int silent)
+static int sel_fill_super(struct super_block *sb, struct fs_context *fc)
{
struct selinux_fs_info *fsi;
int ret;
@@ -2009,10 +2010,19 @@ static int sel_fill_super(struct super_block *sb, void *data, int silent)
return ret;
}
-static struct dentry *sel_mount(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
+static int sel_get_tree(struct fs_context *fc)
{
- return mount_single(fs_type, flags, data, sel_fill_super);
+ return vfs_get_super(fc, vfs_get_single_super, sel_fill_super);
+}
+
+static const struct fs_context_operations sel_context_ops = {
+ .get_tree = sel_get_tree,
+};
+
+static int sel_init_fs_context(struct fs_context *fc)
+{
+ fc->ops = &sel_context_ops;
+ return 0;
}
static void sel_kill_sb(struct super_block *sb)
@@ -2023,7 +2033,7 @@ static void sel_kill_sb(struct super_block *sb)
static struct file_system_type sel_fs_type = {
.name = "selinuxfs",
- .mount = sel_mount,
+ .init_fs_context = sel_init_fs_context,
.kill_sb = sel_kill_sb,
};
^ permalink raw reply related
* [RFC PATCH 38/68] vfs: Convert securityfs to use the new mount API
From: David Howells @ 2019-03-27 23:45 UTC (permalink / raw)
To: viro; +Cc: linux-security-module, linux-fsdevel, linux-kernel, dhowells
In-Reply-To: <155372999953.7602.13784796495137723805.stgit@warthog.procyon.org.uk>
Convert the securityfs filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: linux-security-module@vger.kernel.org
---
security/inode.c | 21 +++++++++++++++------
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/security/inode.c b/security/inode.c
index b7772a9b315e..4fecbc8b072a 100644
--- a/security/inode.c
+++ b/security/inode.c
@@ -16,6 +16,7 @@
#include <linux/sysfs.h>
#include <linux/kobject.h>
#include <linux/fs.h>
+#include <linux/fs_context.h>
#include <linux/mount.h>
#include <linux/pagemap.h>
#include <linux/init.h>
@@ -40,7 +41,7 @@ static const struct super_operations securityfs_super_operations = {
.evict_inode = securityfs_evict_inode,
};
-static int fill_super(struct super_block *sb, void *data, int silent)
+static int securityfs_fill_super(struct super_block *sb, struct fs_context *fc)
{
static const struct tree_descr files[] = {{""}};
int error;
@@ -54,17 +55,25 @@ static int fill_super(struct super_block *sb, void *data, int silent)
return 0;
}
-static struct dentry *get_sb(struct file_system_type *fs_type,
- int flags, const char *dev_name,
- void *data)
+static int securityfs_get_tree(struct fs_context *fc)
{
- return mount_single(fs_type, flags, data, fill_super);
+ return vfs_get_super(fc, vfs_get_single_super, securityfs_fill_super);
+}
+
+static const struct fs_context_operations securityfs_context_ops = {
+ .get_tree = securityfs_get_tree,
+};
+
+static int securityfs_init_fs_context(struct fs_context *fc)
+{
+ fc->ops = &securityfs_context_ops;
+ return 0;
}
static struct file_system_type fs_type = {
.owner = THIS_MODULE,
.name = "securityfs",
- .mount = get_sb,
+ .init_fs_context = securityfs_init_fs_context,
.kill_sb = kill_litter_super,
};
^ permalink raw reply related
* [RFC PATCH 37/68] vfs: Convert apparmorfs to use the new mount API
From: David Howells @ 2019-03-27 23:45 UTC (permalink / raw)
To: viro
Cc: John Johansen, apparmor, linux-security-module, linux-fsdevel,
linux-kernel, dhowells
In-Reply-To: <155372999953.7602.13784796495137723805.stgit@warthog.procyon.org.uk>
Convert the apparmorfs filesystem to the new internal mount API as the old
one will be obsoleted and removed. This allows greater flexibility in
communication of mount parameters between userspace, the VFS and the
filesystem.
See Documentation/filesystems/mount_api.txt for more information.
Signed-off-by: David Howells <dhowells@redhat.com>
cc: John Johansen <john.johansen@canonical.com>
cc: apparmor@lists.ubuntu.com
cc: linux-security-module@vger.kernel.org
---
security/apparmor/apparmorfs.c | 20 +++++++++++++++-----
1 file changed, 15 insertions(+), 5 deletions(-)
diff --git a/security/apparmor/apparmorfs.c b/security/apparmor/apparmorfs.c
index fefee040bf79..75f7da0e5ec1 100644
--- a/security/apparmor/apparmorfs.c
+++ b/security/apparmor/apparmorfs.c
@@ -23,6 +23,7 @@
#include <linux/capability.h>
#include <linux/rcupdate.h>
#include <linux/fs.h>
+#include <linux/fs_context.h>
#include <linux/poll.h>
#include <uapi/linux/major.h>
#include <uapi/linux/magic.h>
@@ -137,7 +138,7 @@ static const struct super_operations aafs_super_ops = {
.show_path = aafs_show_path,
};
-static int fill_super(struct super_block *sb, void *data, int silent)
+static int apparmorfs_fill_super(struct super_block *sb, struct fs_context *fc)
{
static struct tree_descr files[] = { {""} };
int error;
@@ -150,16 +151,25 @@ static int fill_super(struct super_block *sb, void *data, int silent)
return 0;
}
-static struct dentry *aafs_mount(struct file_system_type *fs_type,
- int flags, const char *dev_name, void *data)
+static int apparmorfs_get_tree(struct fs_context *fc)
{
- return mount_single(fs_type, flags, data, fill_super);
+ return vfs_get_super(fc, vfs_get_single_super, apparmorfs_fill_super);
+}
+
+static const struct fs_context_operations apparmorfs_context_ops = {
+ .get_tree = apparmorfs_get_tree,
+};
+
+static int apparmorfs_init_fs_context(struct fs_context *fc)
+{
+ fc->ops = &apparmorfs_context_ops;
+ return 0;
}
static struct file_system_type aafs_ops = {
.owner = THIS_MODULE,
.name = AAFS_NAME,
- .mount = aafs_mount,
+ .init_fs_context = apparmorfs_init_fs_context,
.kill_sb = kill_anon_super,
};
^ permalink raw reply related
* Re: Linux 5.1-rc2
From: Casey Schaufler @ 2019-03-27 23:22 UTC (permalink / raw)
To: Randy Dunlap, Tetsuo Handa, Kees Cook
Cc: James Morris, Linus Torvalds, Linux List Kernel Mailing,
linux-security-module, Jakub Kicinski
In-Reply-To: <366dcec3-1599-9e56-4660-44791e1c7a45@infradead.org>
On 3/27/2019 3:55 PM, Randy Dunlap wrote:
> On 3/27/19 3:23 PM, Casey Schaufler wrote:
>> On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
>>> On 2019/03/28 6:43, Kees Cook wrote:
>>>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>>>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>>>>> situation where this is not true?
>>>>> There should be no problem except some TOMOYO messages are printed.
>>>> Okay, so I should send my latest version of the patch to James? Or do
>>>> you explicitly want TOMOYO removed from all the CONFIG_LSM default
>>>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
>>>> the latter will lead to less testing of the stacking.)
>>>>
>>> My approach is "opt-in" while your approach is "opt-out". And the problem
>>> here is that people might fail to change CONFIG_LSM from the default value
>>> to what they need. (And Jakub did not change CONFIG_LSM to reflect
>>> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
>>> "opt-in" approach; which includes up to only one legacy major LSM and allows
>>> people to change the default value to include multiple legacy major LSMs.
>>>
>>> You can propose your latest version. If SELinux/Smack/AppArmor people
>>> prefer "opt-out" approach, I'm fine with "opt-out" approach.
>> In the long haul we want people to use CONFIG_LSM to set their
>> list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH
>> makes some sense, but it's important that we encourage a mindset change.
>> Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the
>> value from CONFIG_LSM, and make it the default?
>>
> Hi,
>
> I'm still confused. Does this mindset change include removing support of
> SECURITY_DAC?
No.
> If so, where was this discussed and decided?
linux-security-module@vger.kernel.org on threads related to security
module stacking. It's easy to get the same result with a CONFIG_LSM
that includes none of the SELinux, Smack, TOMOYO or AppArmor.
> And if so (again), that feels like enforcing some kind of policy in the kernel.
Again, not so. It's a change from "The not-more-the One Major Module" to
"Whatever set of policies works for you". The NULL set is completely
supported. The current flap is that it's more difficult to express doing
things the old way. Kees and Tetsuo are hashing out how best to support
old .confg files in support of automated tools.
> thanks.
^ permalink raw reply
* Re: Linux 5.1-rc2
From: Randy Dunlap @ 2019-03-27 22:55 UTC (permalink / raw)
To: Casey Schaufler, Tetsuo Handa, Kees Cook
Cc: James Morris, Linus Torvalds, Linux List Kernel Mailing,
linux-security-module, Jakub Kicinski
In-Reply-To: <d067619e-8c7f-94ec-a835-fc86d1b449e3@schaufler-ca.com>
On 3/27/19 3:23 PM, Casey Schaufler wrote:
> On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
>> On 2019/03/28 6:43, Kees Cook wrote:
>>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>>>> situation where this is not true?
>>>> There should be no problem except some TOMOYO messages are printed.
>>> Okay, so I should send my latest version of the patch to James? Or do
>>> you explicitly want TOMOYO removed from all the CONFIG_LSM default
>>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
>>> the latter will lead to less testing of the stacking.)
>>>
>> My approach is "opt-in" while your approach is "opt-out". And the problem
>> here is that people might fail to change CONFIG_LSM from the default value
>> to what they need. (And Jakub did not change CONFIG_LSM to reflect
>> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
>> "opt-in" approach; which includes up to only one legacy major LSM and allows
>> people to change the default value to include multiple legacy major LSMs.
>>
>> You can propose your latest version. If SELinux/Smack/AppArmor people
>> prefer "opt-out" approach, I'm fine with "opt-out" approach.
>
> In the long haul we want people to use CONFIG_LSM to set their
> list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH
> makes some sense, but it's important that we encourage a mindset change.
> Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the
> value from CONFIG_LSM, and make it the default?
>
Hi,
I'm still confused. Does this mindset change include removing support of
SECURITY_DAC? If so, where was this discussed and decided?
And if so (again), that feels like enforcing some kind of policy in the kernel.
thanks.
--
~Randy
^ permalink raw reply
* Re: Linux 5.1-rc2
From: Casey Schaufler @ 2019-03-27 22:23 UTC (permalink / raw)
To: Tetsuo Handa, Kees Cook
Cc: James Morris, Randy Dunlap, Linus Torvalds,
Linux List Kernel Mailing, linux-security-module, Jakub Kicinski
In-Reply-To: <ea75aace-a493-b2fa-1fef-d6ae76085c39@i-love.sakura.ne.jp>
On 3/27/2019 3:05 PM, Tetsuo Handa wrote:
> On 2019/03/28 6:43, Kees Cook wrote:
>>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>>> situation where this is not true?
>>> There should be no problem except some TOMOYO messages are printed.
>> Okay, so I should send my latest version of the patch to James? Or do
>> you explicitly want TOMOYO removed from all the CONFIG_LSM default
>> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
>> the latter will lead to less testing of the stacking.)
>>
> My approach is "opt-in" while your approach is "opt-out". And the problem
> here is that people might fail to change CONFIG_LSM from the default value
> to what they need. (And Jakub did not change CONFIG_LSM to reflect
> CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
> "opt-in" approach; which includes up to only one legacy major LSM and allows
> people to change the default value to include multiple legacy major LSMs.
>
> You can propose your latest version. If SELinux/Smack/AppArmor people
> prefer "opt-out" approach, I'm fine with "opt-out" approach.
In the long haul we want people to use CONFIG_LSM to set their
list of modules. Providing a backward compatible CONFIG_DEFAULT_SECURITY_BLAH
makes some sense, but it's important that we encourage a mindset change.
Maybe with CONFIG_DEFAULT_SECURITY_LIST with a a full list, which uses the
value from CONFIG_LSM, and make it the default?
^ permalink raw reply
* Re: [PATCH ghak109 V2] audit: link integrity evm_write_xattrs record to syscall event
From: Paul Moore @ 2019-03-27 22:14 UTC (permalink / raw)
To: Mimi Zohar, Richard Guy Briggs
Cc: linux-integrity, linux-security-module, Linux-Audit Mailing List,
LKML, sgrubb, omosnace, Eric Paris, Serge Hallyn, mjg59
In-Reply-To: <1553699048.4154.1.camel@linux.ibm.com>
On Wed, Mar 27, 2019 at 11:05 AM Mimi Zohar <zohar@linux.ibm.com> wrote:
> On Tue, 2019-03-26 at 19:58 -0400, Paul Moore wrote:
> > On Tue, Mar 26, 2019 at 4:40 PM Mimi Zohar <zohar@linux.ibm.com> wrote:
> > >
> > > Hi Richard, Paul,
> > >
> > > On Tue, 2019-03-26 at 14:49 -0400, Richard Guy Briggs wrote:
> > > > In commit fa516b66a1bf ("EVM: Allow runtime modification of the set of
> > > > verified xattrs"), the call to audit_log_start() is missing a context to
> > > > link it to an audit event. Since this event is in user context, add
> > > > the process' syscall context to the record.
> > > >
> > > > In addition, the orphaned keyword "locked" appears in the record.
> > > > Normalize this by changing it to logging the locking string "." as any
> > > > other user input in the "xattr=" field.
> > > >
> > > > Please see the github issue
> > > > https://github.com/linux-audit/audit-kernel/issues/109
> > > >
> > > > Signed-off-by: Richard Guy Briggs <rgb@redhat.com>
> > >
> > > Acked-by: Mimi Zohar <zohar@linux.ibm.com>
> > >
> > > Paul, were you planning on upstreaming this patch?
> >
> > Yep, unless you would rather do it?
>
> No, that's fine. Thanks!
Merged into audit/next, thanks all.
--
paul moore
www.paul-moore.com
^ permalink raw reply
* Re: Linux 5.1-rc2
From: Tetsuo Handa @ 2019-03-27 22:05 UTC (permalink / raw)
To: Kees Cook
Cc: James Morris, Randy Dunlap, Linus Torvalds,
Linux List Kernel Mailing, linux-security-module, Jakub Kicinski
In-Reply-To: <CAGXu5jL0YzgQR_p9otyOX4+00a0i7Tfv9aLqauZFZs4-Kfjakg@mail.gmail.com>
On 2019/03/28 6:43, Kees Cook wrote:
>>> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
>>> also initializing TOMOYO, though. It should be a no-op. Is there some
>>> situation where this is not true?
>>
>> There should be no problem except some TOMOYO messages are printed.
>
> Okay, so I should send my latest version of the patch to James? Or do
> you explicitly want TOMOYO removed from all the CONFIG_LSM default
> lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
> the latter will lead to less testing of the stacking.)
>
My approach is "opt-in" while your approach is "opt-out". And the problem
here is that people might fail to change CONFIG_LSM from the default value
to what they need. (And Jakub did not change CONFIG_LSM to reflect
CONFIG_DEFAULT_SECURITY_APPARMOR from the old config.) Thus, I suggest
"opt-in" approach; which includes up to only one legacy major LSM and allows
people to change the default value to include multiple legacy major LSMs.
You can propose your latest version. If SELinux/Smack/AppArmor people
prefer "opt-out" approach, I'm fine with "opt-out" approach.
^ permalink raw reply
* Re: Linux 5.1-rc2
From: Kees Cook @ 2019-03-27 21:43 UTC (permalink / raw)
To: Tetsuo Handa
Cc: James Morris, Randy Dunlap, Linus Torvalds,
Linux List Kernel Mailing, linux-security-module, Jakub Kicinski
In-Reply-To: <e1f6f5a6-9fce-2e95-4593-79f1e836bac5@i-love.sakura.ne.jp>
On Wed, Mar 27, 2019 at 2:05 PM Tetsuo Handa
<penguin-kernel@i-love.sakura.ne.jp> wrote:
>
> On 2019/03/28 5:45, Kees Cook wrote:
> > On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
> > <penguin-kernel@i-love.sakura.ne.jp> wrote:
> >>
> >> On 2019/03/28 4:16, Kees Cook wrote:
> >>> The part I don't understand is what you've said about TOMOYO being
> >>> primary and not wanting the others stackable? That kind of goes
> >>> against the point, but I'm happy to do that if you want it that way.
> >>
> >> Automatically enabling multiple legacy major LSMs might result in a confusion like
> >> Jakub encountered.
> >
> > The confusion wasn't multiple enabled: it was a change of what was
> > enabled (due to ignoring the old config). (My very first suggested
> > patch fixed this...)
>
> Someone else might get confused when TOMOYO is automatically enabled
> despite they did not specify TOMOYO in lsm= or security= or CONFIG_LSM.
>
> >
> >> For a few releases from 5.1 (about one year or so?), since
> >> CONFIG_DEFAULT_SECURITY_* will be ignored after CONFIG_LSM is once defined in
> >> their kernel configs, I guess that it is better not to enable TOMOYO automatically
> >> until most people complete migrating from CONFIG_DEFAULT_SECURITY_* to CONFIG_LSM
> >> and get used to use lsm= kernel command line option rather than security= kernel
> >> command line option.
> >
> > It sounds like you want TOMOYO to stay an exclusive LSM? Should we
> > revert a5e2fe7ede12 ("TOMOYO: Update LSM flags to no longer be
> > exclusive") instead? (I'm against this idea, but defer to you. I think
> > it should stay stackable since the goal is to entirely remove the
> > concept of exclusive LSMs.)
>
> I never want to revert a5e2fe7ede12. For transition period, I just don't
> want to automatically enable TOMOYO when people did not specify TOMOYO.
>
> >
> > I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
> > also initializing TOMOYO, though. It should be a no-op. Is there some
> > situation where this is not true?
>
> There should be no problem except some TOMOYO messages are printed.
Okay, so I should send my latest version of the patch to James? Or do
you explicitly want TOMOYO removed from all the CONFIG_LSM default
lines except when selected by CONFIG_DEFAULT_SECURITY_TOMOYO? (I worry
the latter will lead to less testing of the stacking.)
--
Kees Cook
^ permalink raw reply
* Re: Linux 5.1-rc2
From: Tetsuo Handa @ 2019-03-27 21:05 UTC (permalink / raw)
To: Kees Cook
Cc: James Morris, Randy Dunlap, Linus Torvalds,
Linux List Kernel Mailing, linux-security-module, Jakub Kicinski
In-Reply-To: <CAGXu5jKWECKxksJWPpCkBKG+wB26DhYK=nYBpuuoS+Pv9AsNwQ@mail.gmail.com>
On 2019/03/28 5:45, Kees Cook wrote:
> On Wed, Mar 27, 2019 at 1:30 PM Tetsuo Handa
> <penguin-kernel@i-love.sakura.ne.jp> wrote:
>>
>> On 2019/03/28 4:16, Kees Cook wrote:
>>> The part I don't understand is what you've said about TOMOYO being
>>> primary and not wanting the others stackable? That kind of goes
>>> against the point, but I'm happy to do that if you want it that way.
>>
>> Automatically enabling multiple legacy major LSMs might result in a confusion like
>> Jakub encountered.
>
> The confusion wasn't multiple enabled: it was a change of what was
> enabled (due to ignoring the old config). (My very first suggested
> patch fixed this...)
Someone else might get confused when TOMOYO is automatically enabled
despite they did not specify TOMOYO in lsm= or security= or CONFIG_LSM.
>
>> For a few releases from 5.1 (about one year or so?), since
>> CONFIG_DEFAULT_SECURITY_* will be ignored after CONFIG_LSM is once defined in
>> their kernel configs, I guess that it is better not to enable TOMOYO automatically
>> until most people complete migrating from CONFIG_DEFAULT_SECURITY_* to CONFIG_LSM
>> and get used to use lsm= kernel command line option rather than security= kernel
>> command line option.
>
> It sounds like you want TOMOYO to stay an exclusive LSM? Should we
> revert a5e2fe7ede12 ("TOMOYO: Update LSM flags to no longer be
> exclusive") instead? (I'm against this idea, but defer to you. I think
> it should stay stackable since the goal is to entirely remove the
> concept of exclusive LSMs.)
I never want to revert a5e2fe7ede12. For transition period, I just don't
want to automatically enable TOMOYO when people did not specify TOMOYO.
>
> I don't see problems for an exclusive LSM user (AA, SELinux, Smack)
> also initializing TOMOYO, though. It should be a no-op. Is there some
> situation where this is not true?
There should be no problem except some TOMOYO messages are printed.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox