Comment # 23 on bug 1227282 from Jiri Wiesner

(In reply to Fabian Vogt from comment #21)
> Is this just bug 1197746 again?

Thank you, Fabian. That helped.

(In reply to Cathy Hu from comment #22)
> Looks like it, and the root cause already was debugged as well:
> https://bugzilla.suse.com/show_bug.cgi?id=1197746#c1

I needed to see more data to understand how the errors reported in user space
are caused by the LSMs. There are many errors reported during the boot
sequence. I just took the first error 
systemd[1]: Failed to set SELinux security context
system_u:object_r:device_t:s0 for /dev/core: Invalid argument
and enabled tracing for the kernel:
quiet tp_printk log_buf_len=64M trace_buf_size=8M
kprobe_event=p,do_sys_openat2,path=+0(%si):ustring\;r,do_sys_openat2,\$retval\;p,ksys_write,fd=%di,count=%dx\;r,ksys_write,ret=\$retval\;p,security_setprocattr,lsm=+0(%di):string,lsmp=%di,name=+0(%si):string\;r,security_setprocattr,ret=\$retval

The error is reported after systemd fails to execute setfscreatecon_raw(),
which is implemented by libselinux. The output of the trace shows that it was
the write syscall what returned an error:
> kernel: p_do_sys_openat2_0: (do_sys_openat2+0x0/0x320) path="/proc/thread-self/attr/fscreate"
> kernel: r_do_sys_openat2_0: (do_sys_open+0x57/0x80 <- do_sys_openat2) arg1=0x4
> kernel: p_ksys_write_0: (ksys_write+0x0/0xe0) fd=0x4 count=0x1e
> kernel: p_security_setprocattr_0: (security_setprocattr+0x0/0x70) lsm=(fault) lsmp=0x0 name="fscreate"
> kernel: r_security_setprocattr_0: (proc_pid_attr_write+0x10d/0x160 <- security_setprocattr) ret=0xffffffea
> kernel: r_ksys_write_0: (do_syscall_64+0x5b/0x80 <- ksys_write) ret=0xffffffffffffffea
> systemd[1]: Failed to set SELinux security context system_u:object_r:device_t:s0 for /dev/core: Invalid argument
The error originated from security_setprocattr(), which executed the hook of
the bpf LSM.

This is a successful boot:
> kernel: [    6.779348][    T1] p_do_sys_openat2_0: (do_sys_openat2+0x0/0x320) path="/proc/thread-self/attr/fscreate"
> kernel: [    6.779478][    T1] r_do_sys_openat2_0: (do_sys_open+0x57/0x80 <- do_sys_openat2) arg1=0x4
> kernel: [    6.779486][    T1] p_ksys_write_0: (ksys_write+0x0/0xe0) fd=0x4 count=0x1e
> kernel: [    6.779497][    T1] p_security_setprocattr_0: (security_setprocattr+0x0/0x70) lsm=(fault) lsmp=0x0 name="fscreate"
> kernel: [    6.779508][    T1] r_security_setprocattr_0: (proc_pid_attr_write+0x10d/0x160 <- security_setprocattr) ret=0x1e
> kernel: [    6.779513][    T1] r_ksys_write_0: (do_syscall_64+0x5b/0x80 <- ksys_write) ret=0x1e

> i dont think we can change that in userspace

Yes, it's on the kernel side where improvements need to be made. I have
submitted a commit changing CONFIG_LSM to "integrity,apparmor,selinux,bpf" to
15sp6. This will resolve the issue with the security=selinux parameter but it
will not protect against user error when passing lsm=bpf,selinux to the kernel.
I don't think there is a better solution at the moment. Changing the default
value of selected LSM hooks would be required (I expect resistance against that
upstream), or SUSE would provide BPF code for the LSM hooks causing boot
failure. Both solutions seems overkill when all that is needed it getting the
order of LSMs right.