From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: Casey Schaufler <casey@schaufler-ca.com>, Paul Moore <paul@paul-moore.com> Cc: John Johansen <john.johansen@canonical.com>, LSM List <linux-security-module@vger.kernel.org>, James Morris <jmorris@namei.org>, linux-audit@redhat.com, Mimi Zohar <zohar@linux.ibm.com>, keescook@chromium.org, SElinux list <selinux@vger.kernel.org> Subject: Re: LSM stacking in next for 6.1? Date: Tue, 13 Sep 2022 19:47:38 +0900 [thread overview] Message-ID: <ff43e254-0f41-3f4f-f04d-63b76bed2ccf@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <cc14bbde-529e-376c-7d27-8512ec677db3@schaufler-ca.com> On 2022/09/13 2:37, Casey Schaufler wrote: > That doesn't give us a good answer for loadable modules. The last time I looked > seriously at loadable modules I was considering that we'd need a security module > that manages them, very much like BPF manages the eBPF programs. Loadable modules > could use prctl, or some other mechanism, but they would have to be different > from built-in modules. You can't require built-in modules to conform to the > restrictions you'd have to impose on loadable ones. What I'm requesting (in other words, the biggest barrier I want to solve) is security/security.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/security.c b/security/security.c index 4b95de24bc8d..ed34e25af22b 100644 --- a/security/security.c +++ b/security/security.c @@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = { }; struct security_hook_heads security_hook_heads __lsm_ro_after_init; +EXPORT_SYMBOL_GPL(security_hook_heads); static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain); static struct kmem_cache *lsm_file_cache; -- 2.18.4 and optionally (in other words, the second biggest barrier I want to solve is) security/security.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/security.c b/security/security.c index ed34e25af22b..4cc09e6cb32a 100644 --- a/security/security.c +++ b/security/security.c @@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = { [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality", }; -struct security_hook_heads security_hook_heads __lsm_ro_after_init; +struct security_hook_heads security_hook_heads; EXPORT_SYMBOL_GPL(security_hook_heads); static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain); -- 2.18.4 . A security module that manages loadable LSM modules cannot give us a good answer if there is a kernel config option to disable the manager security module. As long as the death sentence remains, being able to disallow loadable LSMs is a very stupid decision. If a loadable kernel module were malicious, that module can do what AKARI/CaitSith are doing today using more disguised code. There should be a chance for ethical loadable LSM modules. Kernels which seriously need security should be built with CONFIG_MODULES=n. Kernels which want to use loadable modules (not limited to LSM) but still need to remain secure should consider using e.g. CONFIG_MODULE_SIG=y. I consider that real bugs which may crash/compromise the kernel are reported by fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs should be the way to proceed. > The Loadable Module Security > Module would have a static ID and somehow multiplex what lsm_self_attr() reports. I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface, without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid interface/resource conflicts you are trying to solve. > I think it could be made to work. I can't say that it is something I am likely to > get to soon. The kernel config option and distribution's policy are preventing users from using non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work in distributor's kernels if above-mentioned changes are accepted. https://bugzilla.redhat.com/show_bug.cgi?id=542986
WARNING: multiple messages have this Message-ID (diff)
From: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp> To: Casey Schaufler <casey@schaufler-ca.com>, Paul Moore <paul@paul-moore.com> Cc: John Johansen <john.johansen@canonical.com>, SElinux list <selinux@vger.kernel.org>, James Morris <jmorris@namei.org>, Mimi Zohar <zohar@linux.ibm.com>, LSM List <linux-security-module@vger.kernel.org>, linux-audit@redhat.com Subject: Re: LSM stacking in next for 6.1? Date: Tue, 13 Sep 2022 19:47:38 +0900 [thread overview] Message-ID: <ff43e254-0f41-3f4f-f04d-63b76bed2ccf@I-love.SAKURA.ne.jp> (raw) In-Reply-To: <cc14bbde-529e-376c-7d27-8512ec677db3@schaufler-ca.com> On 2022/09/13 2:37, Casey Schaufler wrote: > That doesn't give us a good answer for loadable modules. The last time I looked > seriously at loadable modules I was considering that we'd need a security module > that manages them, very much like BPF manages the eBPF programs. Loadable modules > could use prctl, or some other mechanism, but they would have to be different > from built-in modules. You can't require built-in modules to conform to the > restrictions you'd have to impose on loadable ones. What I'm requesting (in other words, the biggest barrier I want to solve) is security/security.c | 1 + 1 file changed, 1 insertion(+) diff --git a/security/security.c b/security/security.c index 4b95de24bc8d..ed34e25af22b 100644 --- a/security/security.c +++ b/security/security.c @@ -73,6 +73,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = { }; struct security_hook_heads security_hook_heads __lsm_ro_after_init; +EXPORT_SYMBOL_GPL(security_hook_heads); static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain); static struct kmem_cache *lsm_file_cache; -- 2.18.4 and optionally (in other words, the second biggest barrier I want to solve is) security/security.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/security/security.c b/security/security.c index ed34e25af22b..4cc09e6cb32a 100644 --- a/security/security.c +++ b/security/security.c @@ -72,7 +72,7 @@ const char *const lockdown_reasons[LOCKDOWN_CONFIDENTIALITY_MAX+1] = { [LOCKDOWN_CONFIDENTIALITY_MAX] = "confidentiality", }; -struct security_hook_heads security_hook_heads __lsm_ro_after_init; +struct security_hook_heads security_hook_heads; EXPORT_SYMBOL_GPL(security_hook_heads); static BLOCKING_NOTIFIER_HEAD(blocking_lsm_notifier_chain); -- 2.18.4 . A security module that manages loadable LSM modules cannot give us a good answer if there is a kernel config option to disable the manager security module. As long as the death sentence remains, being able to disallow loadable LSMs is a very stupid decision. If a loadable kernel module were malicious, that module can do what AKARI/CaitSith are doing today using more disguised code. There should be a chance for ethical loadable LSM modules. Kernels which seriously need security should be built with CONFIG_MODULES=n. Kernels which want to use loadable modules (not limited to LSM) but still need to remain secure should consider using e.g. CONFIG_MODULE_SIG=y. I consider that real bugs which may crash/compromise the kernel are reported by fuzz testing. Rather than disallowing loadable module LSMs, fixing real bugs should be the way to proceed. > The Loadable Module Security > Module would have a static ID and somehow multiplex what lsm_self_attr() reports. I don't think loadable module LSM have a static ID. TOMOYO/AKARI/CaitSith are already working without "struct lsm_blob_sizes blob_sizes", without /proc/pid/attr/ interface, without modification of userspace programs. TOMOYO/AKARI/CaitSith are designed to avoid interface/resource conflicts you are trying to solve. > I think it could be made to work. I can't say that it is something I am likely to > get to soon. The kernel config option and distribution's policy are preventing users from using non-builtin LSMs in distributor's kernels. It is a trivial task to make TOMOYO work in distributor's kernels if above-mentioned changes are accepted. https://bugzilla.redhat.com/show_bug.cgi?id=542986 -- Linux-audit mailing list Linux-audit@redhat.com https://listman.redhat.com/mailman/listinfo/linux-audit
next prev parent reply other threads:[~2022-09-13 10:47 UTC|newest] Thread overview: 148+ messages / expand[flat|nested] mbox.gz Atom feed top [not found] <791e13b5-bebd-12fc-53de-e9a86df23836.ref@schaufler-ca.com> 2022-08-03 0:01 ` LSM stacking in next for 6.1? Casey Schaufler 2022-08-03 0:01 ` Casey Schaufler 2022-08-03 0:56 ` Paul Moore 2022-08-03 0:56 ` Paul Moore 2022-08-03 1:56 ` John Johansen 2022-08-03 1:56 ` John Johansen 2022-08-03 2:15 ` Casey Schaufler 2022-08-03 2:15 ` Casey Schaufler 2022-08-03 2:33 ` Paul Moore 2022-08-03 2:33 ` Paul Moore 2022-08-03 2:34 ` Steve Grubb 2022-08-03 2:34 ` Steve Grubb 2022-08-03 2:40 ` Paul Moore 2022-08-03 2:40 ` Paul Moore 2022-09-02 21:30 ` Paul Moore 2022-09-02 21:30 ` Paul Moore 2022-09-02 23:14 ` Casey Schaufler 2022-09-02 23:14 ` Casey Schaufler 2022-09-02 23:57 ` Casey Schaufler 2022-09-02 23:57 ` Casey Schaufler 2022-09-06 23:24 ` Paul Moore 2022-09-06 23:24 ` Paul Moore 2022-09-07 0:10 ` John Johansen 2022-09-07 0:10 ` John Johansen 2022-09-07 0:39 ` Casey Schaufler 2022-09-07 0:39 ` Casey Schaufler 2022-09-07 0:50 ` John Johansen 2022-09-07 0:50 ` John Johansen 2022-09-07 14:41 ` Paul Moore 2022-09-07 14:41 ` Paul Moore 2022-09-07 16:41 ` Casey Schaufler 2022-09-07 16:41 ` Casey Schaufler 2022-09-07 17:23 ` John Johansen 2022-09-07 17:23 ` John Johansen 2022-09-07 22:57 ` Paul Moore 2022-09-07 22:57 ` Paul Moore 2022-09-07 23:27 ` Paul Moore 2022-09-07 23:27 ` Paul Moore 2022-09-07 23:53 ` Casey Schaufler 2022-09-07 23:53 ` Casey Schaufler 2022-09-08 0:19 ` John Johansen 2022-09-08 0:19 ` John Johansen 2022-09-08 3:57 ` Paul Moore 2022-09-08 3:57 ` Paul Moore 2022-09-08 18:05 ` Casey Schaufler 2022-09-08 18:05 ` Casey Schaufler 2022-09-08 18:35 ` John Johansen 2022-09-08 18:35 ` John Johansen 2022-09-08 19:32 ` Paul Moore 2022-09-08 19:32 ` Paul Moore 2022-09-08 22:56 ` Casey Schaufler 2022-09-08 22:56 ` Casey Schaufler 2022-09-10 4:17 ` Tetsuo Handa 2022-09-10 4:17 ` Tetsuo Handa 2022-09-12 17:37 ` Casey Schaufler 2022-09-12 17:37 ` Casey Schaufler 2022-09-13 10:47 ` Tetsuo Handa [this message] 2022-09-13 10:47 ` Tetsuo Handa 2022-09-13 14:45 ` Casey Schaufler 2022-09-13 14:45 ` Casey Schaufler 2022-09-14 13:57 ` Tetsuo Handa 2022-09-14 13:57 ` Tetsuo Handa 2022-09-14 15:50 ` Casey Schaufler 2022-09-14 15:50 ` Casey Schaufler 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:54 ` John Johansen 2022-09-15 14:54 ` John Johansen 2022-09-15 7:45 ` John Johansen 2022-09-15 7:45 ` John Johansen 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:27 ` Tetsuo Handa 2022-10-25 9:48 ` Tetsuo Handa 2022-10-25 9:48 ` Tetsuo Handa 2022-10-25 10:26 ` John Johansen 2022-10-25 10:26 ` John Johansen 2022-10-25 11:20 ` Tetsuo Handa 2022-10-25 11:20 ` Tetsuo Handa 2022-10-25 14:12 ` Casey Schaufler 2022-10-25 14:12 ` Casey Schaufler 2022-10-25 22:12 ` Tetsuo Handa 2022-10-25 22:12 ` Tetsuo Handa 2022-10-25 22:41 ` Casey Schaufler 2022-10-25 22:41 ` Casey Schaufler 2022-10-26 10:19 ` Tetsuo Handa 2022-10-26 10:19 ` Tetsuo Handa 2022-10-26 15:30 ` Casey Schaufler 2022-10-26 15:30 ` Casey Schaufler 2022-10-28 10:14 ` John Johansen 2022-10-28 10:14 ` John Johansen 2022-10-30 4:03 ` Tetsuo Handa 2022-10-30 4:03 ` Tetsuo Handa 2022-10-30 7:23 ` John Johansen 2022-10-30 7:23 ` John Johansen 2022-10-30 14:02 ` Tetsuo Handa 2022-10-30 14:02 ` Tetsuo Handa 2022-10-30 16:37 ` Kees Cook 2022-10-30 16:37 ` Kees Cook 2022-10-30 20:56 ` Casey Schaufler 2022-10-30 20:56 ` Casey Schaufler 2022-10-31 10:26 ` Tetsuo Handa 2022-10-31 10:26 ` Tetsuo Handa 2022-10-31 15:47 ` Casey Schaufler 2022-10-31 15:47 ` Casey Schaufler 2022-10-26 20:11 ` Paul Moore 2022-10-26 20:11 ` Paul Moore 2022-10-27 0:02 ` Tetsuo Handa 2022-10-27 0:02 ` Tetsuo Handa 2022-10-28 9:50 ` Paul Moore 2022-10-28 9:50 ` Paul Moore 2022-10-28 13:58 ` Tetsuo Handa 2022-10-28 13:58 ` Tetsuo Handa 2022-10-28 17:40 ` Kees Cook 2022-10-28 17:40 ` Kees Cook 2022-10-29 9:33 ` Tetsuo Handa 2022-10-29 9:33 ` Tetsuo Handa 2022-09-14 13:42 ` Paul Moore 2022-09-14 13:42 ` Paul Moore 2022-09-27 20:54 ` Casey Schaufler 2022-09-27 20:54 ` Casey Schaufler 2022-09-27 22:37 ` Paul Moore 2022-09-27 22:37 ` Paul Moore 2022-09-07 0:31 ` Casey Schaufler 2022-09-07 0:31 ` Casey Schaufler 2022-09-07 15:13 ` Paul Moore 2022-09-07 15:13 ` Paul Moore 2022-09-07 17:08 ` Casey Schaufler 2022-09-07 17:08 ` Casey Schaufler 2022-09-07 23:04 ` Paul Moore 2022-09-07 23:04 ` Paul Moore 2022-09-07 23:26 ` Casey Schaufler 2022-09-07 23:26 ` Casey Schaufler 2022-09-08 15:18 ` Tetsuo Handa 2022-09-08 15:18 ` Tetsuo Handa 2022-09-08 16:00 ` Casey Schaufler 2022-09-08 16:00 ` Casey Schaufler 2022-09-08 18:52 ` Paul Moore 2022-09-08 18:52 ` Paul Moore 2022-09-09 11:32 ` Tetsuo Handa 2022-09-09 11:32 ` Tetsuo Handa 2022-09-14 13:56 ` Paul Moore 2022-09-14 13:56 ` Paul Moore 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 14:27 ` Tetsuo Handa 2022-09-15 15:50 ` Casey Schaufler 2022-09-15 15:50 ` Casey Schaufler 2022-09-16 13:34 ` Tetsuo Handa 2022-09-16 13:34 ` Tetsuo Handa
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=ff43e254-0f41-3f4f-f04d-63b76bed2ccf@I-love.SAKURA.ne.jp \ --to=penguin-kernel@i-love.sakura.ne.jp \ --cc=casey@schaufler-ca.com \ --cc=jmorris@namei.org \ --cc=john.johansen@canonical.com \ --cc=keescook@chromium.org \ --cc=linux-audit@redhat.com \ --cc=linux-security-module@vger.kernel.org \ --cc=paul@paul-moore.com \ --cc=selinux@vger.kernel.org \ --cc=zohar@linux.ibm.com \ /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: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.