[Ocfs2-devel] ocfs2 xattr

[Valentin Vidić]

On Mon, Mar 06, 2023 at 05:58:30PM +0100, Roberto Sassu wrote:
> If there is no hook registering to inode_init_security, theoretically
> the LSM infrastructure should return -EOPNOTSUPP, which causes ocfs2 to
> set si->enable to zero, and not execute the line that causes the kernel
> to panic.
> 
> The problem would arise if somehow the LSM infrastructure returns zero,
> without setting the xattr. That would explain the panic.
> 
> Not sure, I will think more.

Seems you are right. First of all, there is more than one LSM active:

[    0.048241] LSM: initializing lsm=lockdown,capability,landlock,yama,integrity,apparmor,tomoyo,bpf
[    0.048250] landlock: Up and running.
[    0.048250] Yama: becoming mindful.
[    0.048293] AppArmor: AppArmor initialized
[    0.048295] TOMOYO Linux initialized
[    0.048300] LSM support for eBPF active

But from the source it seems that eBPF creates all hooks and returns the
default value of 0 for inode_init_security:

include/linux/lsm_hook_defs.h:LSM_HOOK(int, 0, inode_init_security, struct inode *inode,

kernel/bpf/bpf_lsm.c:#define LSM_HOOK(RET, DEFAULT, NAME, ...)  \
kernel/bpf/bpf_lsm.c:noinline RET bpf_lsm_##NAME(__VA_ARGS__)   \
kernel/bpf/bpf_lsm.c:{                                          \
kernel/bpf/bpf_lsm.c:   return DEFAULT;                         \
kernel/bpf/bpf_lsm.c:}

I suppose the fix would be to change the default value to -EOPNOTSUPP?

-- 
Valentin