* [RFC PATCH 1/2] ima: don't access a file's integrity status before an IMA policy is loaded @ 2021-03-19 20:03 Mimi Zohar 2021-03-19 20:03 ` [RFC PATCH 2/2] integrity: double check iint_cache was initialized Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2021-03-19 20:03 UTC (permalink / raw) To: Dmitry Vyukov Cc: linux-integrity, Test, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers, Mimi Zohar From: Test <test@localhost.localdomain> Only after an IMA policy is loaded, check, save, or update the cached file's integrity status. Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> --- security/integrity/ima/ima_main.c | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/security/integrity/ima/ima_main.c b/security/integrity/ima/ima_main.c index 9ef748ea829f..9d1196f712e1 100644 --- a/security/integrity/ima/ima_main.c +++ b/security/integrity/ima/ima_main.c @@ -606,6 +606,9 @@ void ima_post_create_tmpfile(struct user_namespace *mnt_userns, struct integrity_iint_cache *iint; int must_appraise; + if (!ima_policy_flag || !S_ISREG(inode->i_mode)) + return; + must_appraise = ima_must_appraise(mnt_userns, inode, MAY_ACCESS, FILE_CHECK); if (!must_appraise) @@ -636,6 +639,9 @@ void ima_post_path_mknod(struct user_namespace *mnt_userns, struct inode *inode = dentry->d_inode; int must_appraise; + if (!ima_policy_flag || !S_ISREG(inode->i_mode)) + return; + must_appraise = ima_must_appraise(mnt_userns, inode, MAY_ACCESS, FILE_CHECK); if (!must_appraise) -- 2.27.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-19 20:03 [RFC PATCH 1/2] ima: don't access a file's integrity status before an IMA policy is loaded Mimi Zohar @ 2021-03-19 20:03 ` Mimi Zohar 2021-03-22 7:10 ` Tetsuo Handa 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2021-03-19 20:03 UTC (permalink / raw) To: Dmitry Vyukov Cc: linux-integrity, Test, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers, Mimi Zohar From: Test <test@localhost.localdomain> The integrity's "iint_cache" is initialized at security_init(). Only after an IMA policy is loaded, which is initialized at late_initcall, is a file's integrity status stored in the "iint_cache". All integrity_inode_get() callers first verify that the IMA policy has been loaded, before calling it. Yet for some reason, it is still being called, causing a NULL pointer dereference. As reported by Dmitry Vyukov: in qemu: qemu-system-x86_64 -enable-kvm -machine q35,nvdimm -cpu max,migratable=off -smp 4 -m 4G,slots=4,maxmem=16G -hda wheezy.img -kernel arch/x86/boot/bzImage -nographic -vga std -soundhw all -usb -usbdevice tablet -bt hci -bt device:keyboard -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net nic,model=virtio-net-pci -object memory-backend-file,id=pmem1,share=off,mem-path=/dev/zero,size=64M -device nvdimm,id=nvdimm1,memdev=pmem1 -append "console=ttyS0 root=/dev/sda earlyprintk=serial rodata=n oops=panic panic_on_warn=1 panic=86400 lsm=smack numa=fake=2 nopcid dummy_hcd.num=8" -pidfile vm_pid -m 2G -cpu host But it crashes on NULL deref in integrity_inode_get during boot: Run /sbin/init as init process BUG: kernel NULL pointer dereference, address: 000000000000001c PGD 0 P4D 0 Oops: 0000 [#1] PREEMPT SMP KASAN CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.12.0-rc2+ #97 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-44-g88ab0c15525c-prebuilt.qemu.org 04/01/2014 RIP: 0010:kmem_cache_alloc+0x2b/0x370 mm/slub.c:2920 Code: 57 41 56 41 55 41 54 41 89 f4 55 48 89 fd 53 48 83 ec 10 44 8b 3d d9 1f 90 0b 65 48 8b 04 25 28 00 00 00 48 89 44 24 08 31 c0 <8b> 5f 1c 4cf RSP: 0000:ffffc9000032f9d8 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff888017fc4f00 RCX: 0000000000000000 RDX: ffff888040220000 RSI: 0000000000000c40 RDI: 0000000000000000 RBP: 0000000000000000 R08: 0000000000000000 R09: ffff888019263627 R10: ffffffff83937cd1 R11: 0000000000000000 R12: 0000000000000c40 R13: ffff888019263538 R14: 0000000000000000 R15: 0000000000ffffff FS: 0000000000000000(0000) GS:ffff88802d180000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 000000000000001c CR3: 000000000b48e000 CR4: 0000000000750ee0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 PKRU: 55555554 Call Trace: integrity_inode_get+0x47/0x260 security/integrity/iint.c:105 process_measurement+0x33d/0x17e0 security/integrity/ima/ima_main.c:237 ima_bprm_check+0xde/0x210 security/integrity/ima/ima_main.c:474 security_bprm_check+0x7d/0xa0 security/security.c:845 search_binary_handler fs/exec.c:1708 [inline] exec_binprm fs/exec.c:1761 [inline] bprm_execve fs/exec.c:1830 [inline] bprm_execve+0x764/0x19a0 fs/exec.c:1792 kernel_execve+0x370/0x460 fs/exec.c:1973 try_to_run_init_process+0x14/0x4e init/main.c:1366 kernel_init+0x11d/0x1b8 init/main.c:1477 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: CR2: 000000000000001c ---[ end trace 22d601a500de7d79 ]--- Before calling kmem_cache_alloc(), check that the iint_cache has been initialized. Reported-by: Dmitry Vyukov <dvyukov@google.com> Signed-off-by: Mimi Zohar <zohar@linux.ibm.com> --- security/integrity/iint.c | 9 +++++++++ 1 file changed, 9 insertions(+) diff --git a/security/integrity/iint.c b/security/integrity/iint.c index 1d20003243c3..80b5ae7bb712 100644 --- a/security/integrity/iint.c +++ b/security/integrity/iint.c @@ -97,6 +97,15 @@ struct integrity_iint_cache *integrity_inode_get(struct inode *inode) struct rb_node **p; struct rb_node *node, *parent = NULL; struct integrity_iint_cache *iint, *test_iint; + static int once = 0; + + if (!iint_cache) { /* shouldn't get here */ + if (!once) { + dump_stack(); + once = 1; + } + return NULL; + } iint = integrity_iint_find(inode); if (iint) -- 2.27.0 ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-19 20:03 ` [RFC PATCH 2/2] integrity: double check iint_cache was initialized Mimi Zohar @ 2021-03-22 7:10 ` Tetsuo Handa 2021-03-22 7:53 ` Dmitry Vyukov 0 siblings, 1 reply; 19+ messages in thread From: Tetsuo Handa @ 2021-03-22 7:10 UTC (permalink / raw) To: Mimi Zohar, Dmitry Vyukov Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On 2021/03/20 5:03, Mimi Zohar wrote: > The integrity's "iint_cache" is initialized at security_init(). Only > after an IMA policy is loaded, which is initialized at late_initcall, > is a file's integrity status stored in the "iint_cache". > > All integrity_inode_get() callers first verify that the IMA policy has > been loaded, before calling it. Yet for some reason, it is still being > called, causing a NULL pointer dereference. > > As reported by Dmitry Vyukov: > in qemu: > qemu-system-x86_64 -enable-kvm -machine q35,nvdimm -cpu > max,migratable=off -smp 4 -m 4G,slots=4,maxmem=16G -hda > wheezy.img -kernel arch/x86/boot/bzImage -nographic -vga std > -soundhw all -usb -usbdevice tablet -bt hci -bt device:keyboard > -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net > nic,model=virtio-net-pci -object > memory-backend-file,id=pmem1,share=off,mem-path=/dev/zero,size=64M > -device nvdimm,id=nvdimm1,memdev=pmem1 -append "console=ttyS0 > root=/dev/sda earlyprintk=serial rodata=n oops=panic panic_on_warn=1 > panic=86400 lsm=smack numa=fake=2 nopcid dummy_hcd.num=8" -pidfile > vm_pid -m 2G -cpu host > I tried similar command line (without "-enable-kvm" and without "-cpu host" as I'm running from VMware, without "-soundhw all", without "-machine q35,nvdimm" and "-device nvdimm,id=nvdimm1,memdev=pmem1" etc.) on 5.12-rc4. While I was finally able to hit similar crash when I used "-smp 1" instead of "-smp 4", I suspect this is not a integrity module's problem but a memory initialization/corruption problem, for I got various different crashes (INT3) at memory allocation when I was trimming command line options trying to reproduce the same crash. Dmitry, do you get different crashes by changing command line arguments? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-22 7:10 ` Tetsuo Handa @ 2021-03-22 7:53 ` Dmitry Vyukov 2021-03-23 1:46 ` Tetsuo Handa 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-22 7:53 UTC (permalink / raw) To: Tetsuo Handa Cc: Mimi Zohar, linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Mon, Mar 22, 2021 at 8:11 AM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > On 2021/03/20 5:03, Mimi Zohar wrote: > > The integrity's "iint_cache" is initialized at security_init(). Only > > after an IMA policy is loaded, which is initialized at late_initcall, > > is a file's integrity status stored in the "iint_cache". > > > > All integrity_inode_get() callers first verify that the IMA policy has > > been loaded, before calling it. Yet for some reason, it is still being > > called, causing a NULL pointer dereference. > > > > As reported by Dmitry Vyukov: > > in qemu: > > qemu-system-x86_64 -enable-kvm -machine q35,nvdimm -cpu > > max,migratable=off -smp 4 -m 4G,slots=4,maxmem=16G -hda > > wheezy.img -kernel arch/x86/boot/bzImage -nographic -vga std > > -soundhw all -usb -usbdevice tablet -bt hci -bt device:keyboard > > -net user,host=10.0.2.10,hostfwd=tcp::10022-:22 -net > > nic,model=virtio-net-pci -object > > memory-backend-file,id=pmem1,share=off,mem-path=/dev/zero,size=64M > > -device nvdimm,id=nvdimm1,memdev=pmem1 -append "console=ttyS0 > > root=/dev/sda earlyprintk=serial rodata=n oops=panic panic_on_warn=1 > > panic=86400 lsm=smack numa=fake=2 nopcid dummy_hcd.num=8" -pidfile > > vm_pid -m 2G -cpu host > > > > I tried similar command line (without "-enable-kvm" and without "-cpu host" > as I'm running from VMware, without "-soundhw all", without "-machine q35,nvdimm" > and "-device nvdimm,id=nvdimm1,memdev=pmem1" etc.) on 5.12-rc4. While I was finally > able to hit similar crash when I used "-smp 1" instead of "-smp 4", I suspect > this is not a integrity module's problem but a memory initialization/corruption > problem, for I got various different crashes (INT3) at memory allocation when > I was trimming command line options trying to reproduce the same crash. > > Dmitry, do you get different crashes by changing command line arguments? No, I have not seen any other crashes, one the reported one. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-22 7:53 ` Dmitry Vyukov @ 2021-03-23 1:46 ` Tetsuo Handa 2021-03-23 12:09 ` Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Tetsuo Handa @ 2021-03-23 1:46 UTC (permalink / raw) To: Dmitry Vyukov, Mimi Zohar Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On 2021/03/20 5:03, Mimi Zohar wrote: > The integrity's "iint_cache" is initialized at security_init(). Only > after an IMA policy is loaded, which is initialized at late_initcall, > is a file's integrity status stored in the "iint_cache". > > All integrity_inode_get() callers first verify that the IMA policy has > been loaded, before calling it. Yet for some reason, it is still being > called, causing a NULL pointer dereference. > > qemu-system-x86_64 (...snipped...) lsm=smack (...snipped...) Hmm, why are you using lsm=smack instead of security=smack ? Since use of lsm= overrides CONFIG_LSM="lockdown,yama,safesetid,integrity,tomoyo,smack,bpf" settings, only smack is activated, which means that integrity_iintcache_init() will not be called by DEFINE_LSM(integrity) = { .name = "integrity", .init = integrity_iintcache_init, }; declaration. That's the reason iint_cache == NULL when integrity_inode_get() is called. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-23 1:46 ` Tetsuo Handa @ 2021-03-23 12:09 ` Mimi Zohar 2021-03-23 13:37 ` Tetsuo Handa 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2021-03-23 12:09 UTC (permalink / raw) To: Tetsuo Handa, Dmitry Vyukov Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Tue, 2021-03-23 at 10:46 +0900, Tetsuo Handa wrote: > On 2021/03/20 5:03, Mimi Zohar wrote: > > The integrity's "iint_cache" is initialized at security_init(). Only > > after an IMA policy is loaded, which is initialized at late_initcall, > > is a file's integrity status stored in the "iint_cache". > > > > All integrity_inode_get() callers first verify that the IMA policy has > > been loaded, before calling it. Yet for some reason, it is still being > > called, causing a NULL pointer dereference. > > > > qemu-system-x86_64 (...snipped...) lsm=smack (...snipped...) > > Hmm, why are you using lsm=smack instead of security=smack ? > Since use of lsm= overrides CONFIG_LSM="lockdown,yama,safesetid,integrity,tomoyo,smack,bpf" settings, > only smack is activated, which means that integrity_iintcache_init() will not be called by > > DEFINE_LSM(integrity) = { > .name = "integrity", > .init = integrity_iintcache_init, > }; > > declaration. That's the reason iint_cache == NULL when integrity_inode_get() is called. That's exactly the problem, but since we don't control how the system is configured or which parameters are supplied on the boot command line, the kernel needs to at least provide some explanation instead of dereferencing a NULL pointer. FYI, "security=" is being deprecated. From Documentation/admin- guide/kernel-parameters.txt: security= [SECURITY] Choose a legacy "major" security module to enable at boot. This has been deprecated by the "lsm=" parameter. Please take a look at the newer version of this patch. Do you want to add any tags? thanks, Mimi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-23 12:09 ` Mimi Zohar @ 2021-03-23 13:37 ` Tetsuo Handa 2021-03-23 14:01 ` Tetsuo Handa 0 siblings, 1 reply; 19+ messages in thread From: Tetsuo Handa @ 2021-03-23 13:37 UTC (permalink / raw) To: Mimi Zohar, Dmitry Vyukov Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On 2021/03/23 21:09, Mimi Zohar wrote: > Please take a look at the newer version of this patch. Do you want to > add any tags? Oh, I didn't know that you already posted the newer version. > diff --git a/security/integrity/iint.c b/security/integrity/iint.c > index 1d20003243c3..0ba01847e836 100644 > --- a/security/integrity/iint.c > +++ b/security/integrity/iint.c > @@ -98,6 +98,14 @@ struct integrity_iint_cache *integrity_inode_get(struct inode *inode) > struct rb_node *node, *parent = NULL; > struct integrity_iint_cache *iint, *test_iint; > > + /* > + * The integrity's "iint_cache" is initialized at security_init(), > + * unless it is not included in the ordered list of LSMs enabled > + * on the boot command line. > + */ > + if (!iint_cache) > + panic("%s: lsm=integrity required.\n", __func__); > + This looks strange. If "lsm=" parameter must include "integrity", it implies that nobody is allowed to disable "integrity" at boot. Then, why not unconditionally call integrity_iintcache_init() by not counting on DEFINE_LSM(integrity) declaration? > iint = integrity_iint_find(inode); > if (iint) > return iint; > ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-23 13:37 ` Tetsuo Handa @ 2021-03-23 14:01 ` Tetsuo Handa 2021-03-23 14:47 ` Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Tetsuo Handa @ 2021-03-23 14:01 UTC (permalink / raw) To: Mimi Zohar, Dmitry Vyukov Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On 2021/03/23 22:37, Tetsuo Handa wrote: > On 2021/03/23 21:09, Mimi Zohar wrote: >> Please take a look at the newer version of this patch. Do you want to >> add any tags? > > Oh, I didn't know that you already posted the newer version. > >> diff --git a/security/integrity/iint.c b/security/integrity/iint.c >> index 1d20003243c3..0ba01847e836 100644 >> --- a/security/integrity/iint.c >> +++ b/security/integrity/iint.c >> @@ -98,6 +98,14 @@ struct integrity_iint_cache *integrity_inode_get(struct inode *inode) >> struct rb_node *node, *parent = NULL; >> struct integrity_iint_cache *iint, *test_iint; >> >> + /* >> + * The integrity's "iint_cache" is initialized at security_init(), >> + * unless it is not included in the ordered list of LSMs enabled >> + * on the boot command line. >> + */ >> + if (!iint_cache) >> + panic("%s: lsm=integrity required.\n", __func__); >> + > > This looks strange. If "lsm=" parameter must include "integrity", > it implies that nobody is allowed to disable "integrity" at boot. > Then, why not unconditionally call integrity_iintcache_init() by > not counting on DEFINE_LSM(integrity) declaration? Or, I think below one is also possible. diff --git a/security/integrity/iint.c b/security/integrity/iint.c index 1d20003243c3..37afc5168891 100644 --- a/security/integrity/iint.c +++ b/security/integrity/iint.c @@ -19,6 +19,7 @@ #include <linux/uaccess.h> #include <linux/security.h> #include <linux/lsm_hooks.h> +#include <linux/sched/mm.h> #include "integrity.h" static struct rb_root integrity_iint_tree = RB_ROOT; @@ -85,6 +86,20 @@ static void iint_free(struct integrity_iint_cache *iint) kmem_cache_free(iint_cache, iint); } +static void init_once(void *foo) +{ + struct integrity_iint_cache *iint = foo; + + memset(iint, 0, sizeof(*iint)); + iint->ima_file_status = INTEGRITY_UNKNOWN; + iint->ima_mmap_status = INTEGRITY_UNKNOWN; + iint->ima_bprm_status = INTEGRITY_UNKNOWN; + iint->ima_read_status = INTEGRITY_UNKNOWN; + iint->ima_creds_status = INTEGRITY_UNKNOWN; + iint->evm_status = INTEGRITY_UNKNOWN; + mutex_init(&iint->mutex); +} + /** * integrity_inode_get - find or allocate an iint associated with an inode * @inode: pointer to the inode @@ -102,6 +117,18 @@ struct integrity_iint_cache *integrity_inode_get(struct inode *inode) if (iint) return iint; + if (!iint_cache) { + static DEFINE_MUTEX(lock); + unsigned int flags = memalloc_nofs_save(); + + mutex_lock(&lock); + if (!iint_cache) + iint_cache = kmem_cache_create("iint_cache", + sizeof(struct integrity_iint_cache), + 0, SLAB_PANIC, init_once); + mutex_unlock(&lock); + memalloc_nofs_restore(flags); + } iint = kmem_cache_alloc(iint_cache, GFP_NOFS); if (!iint) return NULL; @@ -150,25 +177,8 @@ void integrity_inode_free(struct inode *inode) iint_free(iint); } -static void init_once(void *foo) -{ - struct integrity_iint_cache *iint = foo; - - memset(iint, 0, sizeof(*iint)); - iint->ima_file_status = INTEGRITY_UNKNOWN; - iint->ima_mmap_status = INTEGRITY_UNKNOWN; - iint->ima_bprm_status = INTEGRITY_UNKNOWN; - iint->ima_read_status = INTEGRITY_UNKNOWN; - iint->ima_creds_status = INTEGRITY_UNKNOWN; - iint->evm_status = INTEGRITY_UNKNOWN; - mutex_init(&iint->mutex); -} - static int __init integrity_iintcache_init(void) { - iint_cache = - kmem_cache_create("iint_cache", sizeof(struct integrity_iint_cache), - 0, SLAB_PANIC, init_once); return 0; } DEFINE_LSM(integrity) = { ^ permalink raw reply related [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-23 14:01 ` Tetsuo Handa @ 2021-03-23 14:47 ` Mimi Zohar 2021-03-23 15:14 ` Tetsuo Handa 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2021-03-23 14:47 UTC (permalink / raw) To: Tetsuo Handa, Dmitry Vyukov Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Tue, 2021-03-23 at 23:01 +0900, Tetsuo Handa wrote: > On 2021/03/23 22:37, Tetsuo Handa wrote: > > On 2021/03/23 21:09, Mimi Zohar wrote: > >> Please take a look at the newer version of this patch. Do you want to > >> add any tags? > > > > Oh, I didn't know that you already posted the newer version. > > > >> diff --git a/security/integrity/iint.c b/security/integrity/iint.c > >> index 1d20003243c3..0ba01847e836 100644 > >> --- a/security/integrity/iint.c > >> +++ b/security/integrity/iint.c > >> @@ -98,6 +98,14 @@ struct integrity_iint_cache *integrity_inode_get(struct inode *inode) > >> struct rb_node *node, *parent = NULL; > >> struct integrity_iint_cache *iint, *test_iint; > >> > >> + /* > >> + * The integrity's "iint_cache" is initialized at security_init(), > >> + * unless it is not included in the ordered list of LSMs enabled > >> + * on the boot command line. > >> + */ > >> + if (!iint_cache) > >> + panic("%s: lsm=integrity required.\n", __func__); > >> + > > > > This looks strange. If "lsm=" parameter must include "integrity", > > it implies that nobody is allowed to disable "integrity" at boot. Integrity isn't always required. Only when something tries to use it, does it need to be enabled. Since both integrity and the integrity caller are runtime dependent, it is up to the user/admin to specify "integrity" as an "lsm=" option. > > Then, why not unconditionally call integrity_iintcache_init() by > > not counting on DEFINE_LSM(integrity) declaration? Initially I also questioned making "integrity" an LSM. Perhaps it's time to reconsider. For now, it makes sense to just fix the NULL pointer dereferencing. Mimi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-23 14:47 ` Mimi Zohar @ 2021-03-23 15:14 ` Tetsuo Handa 2021-03-23 16:13 ` Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Tetsuo Handa @ 2021-03-23 15:14 UTC (permalink / raw) To: Mimi Zohar, Dmitry Vyukov Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On 2021/03/23 23:47, Mimi Zohar wrote: > Initially I also questioned making "integrity" an LSM. Perhaps it's > time to reconsider. For now, it makes sense to just fix the NULL > pointer dereferencing. Do we think calling panic() as "fix the NULL pointer dereferencing" ? ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-23 15:14 ` Tetsuo Handa @ 2021-03-23 16:13 ` Mimi Zohar 2021-03-24 10:10 ` Tetsuo Handa 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2021-03-23 16:13 UTC (permalink / raw) To: Tetsuo Handa, Dmitry Vyukov Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: > On 2021/03/23 23:47, Mimi Zohar wrote: > > Initially I also questioned making "integrity" an LSM. Perhaps it's > > time to reconsider. For now, it makes sense to just fix the NULL > > pointer dereferencing. > > Do we think calling panic() as "fix the NULL pointer dereferencing" ? Not supplying "integrity" as an "lsm=" option is a user error. There are only two options - allow or deny the caller to proceed. If the user is expecting the integrity subsystem to be properly working, returning a NULL and allowing the system to boot (RFC patch version) does not make sense. Better to fail early. Mimi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-23 16:13 ` Mimi Zohar @ 2021-03-24 10:10 ` Tetsuo Handa 2021-03-24 11:10 ` Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Tetsuo Handa @ 2021-03-24 10:10 UTC (permalink / raw) To: Mimi Zohar Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers, Dmitry Vyukov On 2021/03/24 1:13, Mimi Zohar wrote: > On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: >> On 2021/03/23 23:47, Mimi Zohar wrote: >>> Initially I also questioned making "integrity" an LSM. Perhaps it's >>> time to reconsider. For now, it makes sense to just fix the NULL >>> pointer dereferencing. >> >> Do we think calling panic() as "fix the NULL pointer dereferencing" ? > > Not supplying "integrity" as an "lsm=" option is a user error. There > are only two options - allow or deny the caller to proceed. If the > user is expecting the integrity subsystem to be properly working, > returning a NULL and allowing the system to boot (RFC patch version) > does not make sense. Better to fail early. What does the "user" mean? Those who load the vmlinux? Only the "root" user (so called administrators)? Any users including other than "root" user? If the user means those who load the vmlinux, that user is explicitly asking for disabling "integrity" for some reason. In that case, it is a bug if booting with "integrity" disabled is impossible. If the user means something other than those who load the vmlinux, is there a possibility that that user (especially non "root" users) is allowed to try to use "integrity" ? If processes other than global init process can try to use "integrity", wouldn't it be a DoS attack vector? Please explain in the descripotion why calling panic() does not cause DoS attack vector. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-24 10:10 ` Tetsuo Handa @ 2021-03-24 11:10 ` Mimi Zohar 2021-03-24 11:20 ` Tetsuo Handa 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2021-03-24 11:10 UTC (permalink / raw) To: Tetsuo Handa Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers, Dmitry Vyukov On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote: > On 2021/03/24 1:13, Mimi Zohar wrote: > > On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: > >> On 2021/03/23 23:47, Mimi Zohar wrote: > >>> Initially I also questioned making "integrity" an LSM. Perhaps it's > >>> time to reconsider. For now, it makes sense to just fix the NULL > >>> pointer dereferencing. > >> > >> Do we think calling panic() as "fix the NULL pointer dereferencing" ? > > > > Not supplying "integrity" as an "lsm=" option is a user error. There > > are only two options - allow or deny the caller to proceed. If the > > user is expecting the integrity subsystem to be properly working, > > returning a NULL and allowing the system to boot (RFC patch version) > > does not make sense. Better to fail early. > > What does the "user" mean? Those who load the vmlinux? > Only the "root" user (so called administrators)? > Any users including other than "root" user? > > If the user means those who load the vmlinux, that user is explicitly asking > for disabling "integrity" for some reason. In that case, it is a bug if > booting with "integrity" disabled is impossible. > > If the user means something other than those who load the vmlinux, > is there a possibility that that user (especially non "root" users) is > allowed to try to use "integrity" ? If processes other than global init > process can try to use "integrity", wouldn't it be a DoS attack vector? > Please explain in the descripotion why calling panic() does not cause > DoS attack vector. User in this case, is anyone rebooting the system and is intentionally changing the default values, dropping the "integrity" option on the boot command line. Mimi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-24 11:10 ` Mimi Zohar @ 2021-03-24 11:20 ` Tetsuo Handa 2021-03-24 11:37 ` Dmitry Vyukov 0 siblings, 1 reply; 19+ messages in thread From: Tetsuo Handa @ 2021-03-24 11:20 UTC (permalink / raw) To: Mimi Zohar Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers, Dmitry Vyukov On 2021/03/24 20:10, Mimi Zohar wrote: > On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote: >> On 2021/03/24 1:13, Mimi Zohar wrote: >>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: >>>> On 2021/03/23 23:47, Mimi Zohar wrote: >>>>> Initially I also questioned making "integrity" an LSM. Perhaps it's >>>>> time to reconsider. For now, it makes sense to just fix the NULL >>>>> pointer dereferencing. >>>> >>>> Do we think calling panic() as "fix the NULL pointer dereferencing" ? >>> >>> Not supplying "integrity" as an "lsm=" option is a user error. There >>> are only two options - allow or deny the caller to proceed. If the >>> user is expecting the integrity subsystem to be properly working, >>> returning a NULL and allowing the system to boot (RFC patch version) >>> does not make sense. Better to fail early. >> >> What does the "user" mean? Those who load the vmlinux? >> Only the "root" user (so called administrators)? >> Any users including other than "root" user? >> >> If the user means those who load the vmlinux, that user is explicitly asking >> for disabling "integrity" for some reason. In that case, it is a bug if >> booting with "integrity" disabled is impossible. >> >> If the user means something other than those who load the vmlinux, >> is there a possibility that that user (especially non "root" users) is >> allowed to try to use "integrity" ? If processes other than global init >> process can try to use "integrity", wouldn't it be a DoS attack vector? >> Please explain in the descripotion why calling panic() does not cause >> DoS attack vector. > > User in this case, is anyone rebooting the system and is intentionally > changing the default values, dropping the "integrity" option on the > boot command line. OK. Then, I expect that the system boots instead of calling panic(). That user is explicitly asking for disabling "integrity" for some reason. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-24 11:20 ` Tetsuo Handa @ 2021-03-24 11:37 ` Dmitry Vyukov 2021-03-24 11:49 ` Mimi Zohar 0 siblings, 1 reply; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-24 11:37 UTC (permalink / raw) To: Tetsuo Handa Cc: Mimi Zohar, linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Wed, Mar 24, 2021 at 12:21 PM Tetsuo Handa <penguin-kernel@i-love.sakura.ne.jp> wrote: > > On 2021/03/24 20:10, Mimi Zohar wrote: > > On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote: > >> On 2021/03/24 1:13, Mimi Zohar wrote: > >>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: > >>>> On 2021/03/23 23:47, Mimi Zohar wrote: > >>>>> Initially I also questioned making "integrity" an LSM. Perhaps it's > >>>>> time to reconsider. For now, it makes sense to just fix the NULL > >>>>> pointer dereferencing. > >>>> > >>>> Do we think calling panic() as "fix the NULL pointer dereferencing" ? > >>> > >>> Not supplying "integrity" as an "lsm=" option is a user error. There > >>> are only two options - allow or deny the caller to proceed. If the > >>> user is expecting the integrity subsystem to be properly working, > >>> returning a NULL and allowing the system to boot (RFC patch version) > >>> does not make sense. Better to fail early. > >> > >> What does the "user" mean? Those who load the vmlinux? > >> Only the "root" user (so called administrators)? > >> Any users including other than "root" user? > >> > >> If the user means those who load the vmlinux, that user is explicitly asking > >> for disabling "integrity" for some reason. In that case, it is a bug if > >> booting with "integrity" disabled is impossible. > >> > >> If the user means something other than those who load the vmlinux, > >> is there a possibility that that user (especially non "root" users) is > >> allowed to try to use "integrity" ? If processes other than global init > >> process can try to use "integrity", wouldn't it be a DoS attack vector? > >> Please explain in the descripotion why calling panic() does not cause > >> DoS attack vector. > > > > User in this case, is anyone rebooting the system and is intentionally > > changing the default values, dropping the "integrity" option on the > > boot command line. > > OK. Then, I expect that the system boots instead of calling panic(). > That user is explicitly asking for disabling "integrity" for some reason. That was actually my intention. The prebuilt kernel that I use for things has all LSMs enabled, but then I needed to try some workload with only 1 specific LSM, so I gave a different lsm= argument. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-24 11:37 ` Dmitry Vyukov @ 2021-03-24 11:49 ` Mimi Zohar 2021-03-24 11:58 ` Dmitry Vyukov 0 siblings, 1 reply; 19+ messages in thread From: Mimi Zohar @ 2021-03-24 11:49 UTC (permalink / raw) To: Dmitry Vyukov, Tetsuo Handa Cc: linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Wed, 2021-03-24 at 12:37 +0100, Dmitry Vyukov wrote: > On Wed, Mar 24, 2021 at 12:21 PM Tetsuo Handa > <penguin-kernel@i-love.sakura.ne.jp> wrote: > > > > On 2021/03/24 20:10, Mimi Zohar wrote: > > > On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote: > > >> On 2021/03/24 1:13, Mimi Zohar wrote: > > >>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: > > >>>> On 2021/03/23 23:47, Mimi Zohar wrote: > > >>>>> Initially I also questioned making "integrity" an LSM. Perhaps it's > > >>>>> time to reconsider. For now, it makes sense to just fix the NULL > > >>>>> pointer dereferencing. > > >>>> > > >>>> Do we think calling panic() as "fix the NULL pointer dereferencing" ? > > >>> > > >>> Not supplying "integrity" as an "lsm=" option is a user error. There > > >>> are only two options - allow or deny the caller to proceed. If the > > >>> user is expecting the integrity subsystem to be properly working, > > >>> returning a NULL and allowing the system to boot (RFC patch version) > > >>> does not make sense. Better to fail early. > > >> > > >> What does the "user" mean? Those who load the vmlinux? > > >> Only the "root" user (so called administrators)? > > >> Any users including other than "root" user? > > >> > > >> If the user means those who load the vmlinux, that user is explicitly asking > > >> for disabling "integrity" for some reason. In that case, it is a bug if > > >> booting with "integrity" disabled is impossible. > > >> > > >> If the user means something other than those who load the vmlinux, > > >> is there a possibility that that user (especially non "root" users) is > > >> allowed to try to use "integrity" ? If processes other than global init > > >> process can try to use "integrity", wouldn't it be a DoS attack vector? > > >> Please explain in the descripotion why calling panic() does not cause > > >> DoS attack vector. > > > > > > User in this case, is anyone rebooting the system and is intentionally > > > changing the default values, dropping the "integrity" option on the > > > boot command line. > > > > OK. Then, I expect that the system boots instead of calling panic(). > > That user is explicitly asking for disabling "integrity" for some reason. > > That was actually my intention. The prebuilt kernel that I use for > things has all LSMs enabled, but then I needed to try some workload > with only 1 specific LSM, so I gave a different lsm= argument. IMA/EVM is dependent on "integrity". Was your intention to also disable IMA and EVM? If so, when disabling "integrity", don't load an IMA policy. Mimi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-24 11:49 ` Mimi Zohar @ 2021-03-24 11:58 ` Dmitry Vyukov 2021-03-24 12:17 ` Mimi Zohar 2021-03-24 15:56 ` Casey Schaufler 0 siblings, 2 replies; 19+ messages in thread From: Dmitry Vyukov @ 2021-03-24 11:58 UTC (permalink / raw) To: Mimi Zohar Cc: Tetsuo Handa, linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Wed, Mar 24, 2021 at 12:49 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > On Wed, 2021-03-24 at 12:37 +0100, Dmitry Vyukov wrote: > > On Wed, Mar 24, 2021 at 12:21 PM Tetsuo Handa > > <penguin-kernel@i-love.sakura.ne.jp> wrote: > > > > > > On 2021/03/24 20:10, Mimi Zohar wrote: > > > > On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote: > > > >> On 2021/03/24 1:13, Mimi Zohar wrote: > > > >>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: > > > >>>> On 2021/03/23 23:47, Mimi Zohar wrote: > > > >>>>> Initially I also questioned making "integrity" an LSM. Perhaps it's > > > >>>>> time to reconsider. For now, it makes sense to just fix the NULL > > > >>>>> pointer dereferencing. > > > >>>> > > > >>>> Do we think calling panic() as "fix the NULL pointer dereferencing" ? > > > >>> > > > >>> Not supplying "integrity" as an "lsm=" option is a user error. There > > > >>> are only two options - allow or deny the caller to proceed. If the > > > >>> user is expecting the integrity subsystem to be properly working, > > > >>> returning a NULL and allowing the system to boot (RFC patch version) > > > >>> does not make sense. Better to fail early. > > > >> > > > >> What does the "user" mean? Those who load the vmlinux? > > > >> Only the "root" user (so called administrators)? > > > >> Any users including other than "root" user? > > > >> > > > >> If the user means those who load the vmlinux, that user is explicitly asking > > > >> for disabling "integrity" for some reason. In that case, it is a bug if > > > >> booting with "integrity" disabled is impossible. > > > >> > > > >> If the user means something other than those who load the vmlinux, > > > >> is there a possibility that that user (especially non "root" users) is > > > >> allowed to try to use "integrity" ? If processes other than global init > > > >> process can try to use "integrity", wouldn't it be a DoS attack vector? > > > >> Please explain in the descripotion why calling panic() does not cause > > > >> DoS attack vector. > > > > > > > > User in this case, is anyone rebooting the system and is intentionally > > > > changing the default values, dropping the "integrity" option on the > > > > boot command line. > > > > > > OK. Then, I expect that the system boots instead of calling panic(). > > > That user is explicitly asking for disabling "integrity" for some reason. > > > > That was actually my intention. The prebuilt kernel that I use for > > things has all LSMs enabled, but then I needed to try some workload > > with only 1 specific LSM, so I gave a different lsm= argument. > > IMA/EVM is dependent on "integrity". Was your intention to also > disable IMA and EVM? I think, yes... or not sure. I was trying to test a bug that requires a different major LSM and all minor LSMs are presumably irrelevant. I dropped existing lsm= arg and added something like lsm=apparmor. > If so, when disabling "integrity", don't load an > IMA policy. I don't really know what this means. I guess it simply comes from the image? If so, there was no easy way to avoid loading. ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-24 11:58 ` Dmitry Vyukov @ 2021-03-24 12:17 ` Mimi Zohar 2021-03-24 15:56 ` Casey Schaufler 1 sibling, 0 replies; 19+ messages in thread From: Mimi Zohar @ 2021-03-24 12:17 UTC (permalink / raw) To: Dmitry Vyukov Cc: Tetsuo Handa, linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers On Wed, 2021-03-24 at 12:58 +0100, Dmitry Vyukov wrote: > On Wed, Mar 24, 2021 at 12:49 PM Mimi Zohar <zohar@linux.ibm.com> wrote: > > > > On Wed, 2021-03-24 at 12:37 +0100, Dmitry Vyukov wrote: > > > On Wed, Mar 24, 2021 at 12:21 PM Tetsuo Handa > > > <penguin-kernel@i-love.sakura.ne.jp> wrote: > > > > > > > > On 2021/03/24 20:10, Mimi Zohar wrote: > > > > > On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote: > > > > >> On 2021/03/24 1:13, Mimi Zohar wrote: > > > > >>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: > > > > >>>> On 2021/03/23 23:47, Mimi Zohar wrote: > > > > >>>>> Initially I also questioned making "integrity" an LSM. Perhaps it's > > > > >>>>> time to reconsider. For now, it makes sense to just fix the NULL > > > > >>>>> pointer dereferencing. > > > > >>>> > > > > >>>> Do we think calling panic() as "fix the NULL pointer dereferencing" ? > > > > >>> > > > > >>> Not supplying "integrity" as an "lsm=" option is a user error. There > > > > >>> are only two options - allow or deny the caller to proceed. If the > > > > >>> user is expecting the integrity subsystem to be properly working, > > > > >>> returning a NULL and allowing the system to boot (RFC patch version) > > > > >>> does not make sense. Better to fail early. > > > > >> > > > > >> What does the "user" mean? Those who load the vmlinux? > > > > >> Only the "root" user (so called administrators)? > > > > >> Any users including other than "root" user? > > > > >> > > > > >> If the user means those who load the vmlinux, that user is explicitly asking > > > > >> for disabling "integrity" for some reason. In that case, it is a bug if > > > > >> booting with "integrity" disabled is impossible. > > > > >> > > > > >> If the user means something other than those who load the vmlinux, > > > > >> is there a possibility that that user (especially non "root" users) is > > > > >> allowed to try to use "integrity" ? If processes other than global init > > > > >> process can try to use "integrity", wouldn't it be a DoS attack vector? > > > > >> Please explain in the descripotion why calling panic() does not cause > > > > >> DoS attack vector. > > > > > > > > > > User in this case, is anyone rebooting the system and is intentionally > > > > > changing the default values, dropping the "integrity" option on the > > > > > boot command line. > > > > > > > > OK. Then, I expect that the system boots instead of calling panic(). > > > > That user is explicitly asking for disabling "integrity" for some reason. > > > > > > That was actually my intention. The prebuilt kernel that I use for > > > things has all LSMs enabled, but then I needed to try some workload > > > with only 1 specific LSM, so I gave a different lsm= argument. > > > > IMA/EVM is dependent on "integrity". Was your intention to also > > disable IMA and EVM? > > I think, yes... or not sure. I was trying to test a bug that requires > a different major LSM and all minor LSMs are presumably irrelevant. I > dropped existing lsm= arg and added something like lsm=apparmor. > > > If so, when disabling "integrity", don't load an > > IMA policy. > > I don't really know what this means. I guess it simply comes from the > image? If so, there was no easy way to avoid loading. There are a couple of builtin IMA policies, which may be loaded on boot by specifying on the boot command line "ima_policy=". Unless the boot command line "ima_policy=" option is specified, no policy will loaded. A custom IMA policy may subsequently be loaded, normally in the initramfs, by echo'ing the file pathname to /sys/kernel/security/ima/policy. Mimi ^ permalink raw reply [flat|nested] 19+ messages in thread
* Re: [RFC PATCH 2/2] integrity: double check iint_cache was initialized 2021-03-24 11:58 ` Dmitry Vyukov 2021-03-24 12:17 ` Mimi Zohar @ 2021-03-24 15:56 ` Casey Schaufler 1 sibling, 0 replies; 19+ messages in thread From: Casey Schaufler @ 2021-03-24 15:56 UTC (permalink / raw) To: Dmitry Vyukov, Mimi Zohar Cc: Tetsuo Handa, linux-integrity, James Morris, Serge E . Hallyn, linux-security-module, LKML, Eric Biggers, Casey Schaufler On 3/24/2021 4:58 AM, Dmitry Vyukov wrote: > On Wed, Mar 24, 2021 at 12:49 PM Mimi Zohar <zohar@linux.ibm.com> wrote: >> On Wed, 2021-03-24 at 12:37 +0100, Dmitry Vyukov wrote: >>> On Wed, Mar 24, 2021 at 12:21 PM Tetsuo Handa >>> <penguin-kernel@i-love.sakura.ne.jp> wrote: >>>> On 2021/03/24 20:10, Mimi Zohar wrote: >>>>> On Wed, 2021-03-24 at 19:10 +0900, Tetsuo Handa wrote: >>>>>> On 2021/03/24 1:13, Mimi Zohar wrote: >>>>>>> On Wed, 2021-03-24 at 00:14 +0900, Tetsuo Handa wrote: >>>>>>>> On 2021/03/23 23:47, Mimi Zohar wrote: >>>>>>>>> Initially I also questioned making "integrity" an LSM. Perhaps it's >>>>>>>>> time to reconsider. For now, it makes sense to just fix the NULL >>>>>>>>> pointer dereferencing. >>>>>>>> Do we think calling panic() as "fix the NULL pointer dereferencing" ? >>>>>>> Not supplying "integrity" as an "lsm=" option is a user error. There >>>>>>> are only two options - allow or deny the caller to proceed. If the >>>>>>> user is expecting the integrity subsystem to be properly working, >>>>>>> returning a NULL and allowing the system to boot (RFC patch version) >>>>>>> does not make sense. Better to fail early. >>>>>> What does the "user" mean? Those who load the vmlinux? >>>>>> Only the "root" user (so called administrators)? >>>>>> Any users including other than "root" user? >>>>>> >>>>>> If the user means those who load the vmlinux, that user is explicitly asking >>>>>> for disabling "integrity" for some reason. In that case, it is a bug if >>>>>> booting with "integrity" disabled is impossible. >>>>>> >>>>>> If the user means something other than those who load the vmlinux, >>>>>> is there a possibility that that user (especially non "root" users) is >>>>>> allowed to try to use "integrity" ? If processes other than global init >>>>>> process can try to use "integrity", wouldn't it be a DoS attack vector? >>>>>> Please explain in the descripotion why calling panic() does not cause >>>>>> DoS attack vector. >>>>> User in this case, is anyone rebooting the system and is intentionally >>>>> changing the default values, dropping the "integrity" option on the >>>>> boot command line. >>>> OK. Then, I expect that the system boots instead of calling panic(). >>>> That user is explicitly asking for disabling "integrity" for some reason. >>> That was actually my intention. The prebuilt kernel that I use for >>> things has all LSMs enabled, but then I needed to try some workload >>> with only 1 specific LSM, so I gave a different lsm= argument. >> IMA/EVM is dependent on "integrity". Was your intention to also >> disable IMA and EVM? > I think, yes... or not sure. I was trying to test a bug that requires > a different major LSM and all minor LSMs are presumably irrelevant. I > dropped existing lsm= arg and added something like lsm=apparmor. This is the legacy case that security= supports. If you specify security=apparmor you will get all the "minor" LSMs you have compiled in and the "major" LSM you've specified, AppArmor in this case. This is exactly the behavior you used to get before lsm= was introduced. > >> If so, when disabling "integrity", don't load an >> IMA policy. > I don't really know what this means. I guess it simply comes from the > image? If so, there was no easy way to avoid loading. ^ permalink raw reply [flat|nested] 19+ messages in thread
end of thread, other threads:[~2021-03-24 15:57 UTC | newest] Thread overview: 19+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-03-19 20:03 [RFC PATCH 1/2] ima: don't access a file's integrity status before an IMA policy is loaded Mimi Zohar 2021-03-19 20:03 ` [RFC PATCH 2/2] integrity: double check iint_cache was initialized Mimi Zohar 2021-03-22 7:10 ` Tetsuo Handa 2021-03-22 7:53 ` Dmitry Vyukov 2021-03-23 1:46 ` Tetsuo Handa 2021-03-23 12:09 ` Mimi Zohar 2021-03-23 13:37 ` Tetsuo Handa 2021-03-23 14:01 ` Tetsuo Handa 2021-03-23 14:47 ` Mimi Zohar 2021-03-23 15:14 ` Tetsuo Handa 2021-03-23 16:13 ` Mimi Zohar 2021-03-24 10:10 ` Tetsuo Handa 2021-03-24 11:10 ` Mimi Zohar 2021-03-24 11:20 ` Tetsuo Handa 2021-03-24 11:37 ` Dmitry Vyukov 2021-03-24 11:49 ` Mimi Zohar 2021-03-24 11:58 ` Dmitry Vyukov 2021-03-24 12:17 ` Mimi Zohar 2021-03-24 15:56 ` Casey Schaufler
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).