Description of problem: Pretty much any NetworkManager operation in Fedora 37 causes this denial: audit: type=1400 audit(1661925248.838:5469): avc: denied { sys_admin } for pid=60445 comm="mv" capability=21 scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tclass=capability permissive=0 Version-Release number of selected component (if applicable): NetworkManager-1.39.90-1.fc37.x86_64 selinux-policy-37.8-1.fc37.noarch How reproducible: Always Steps to Reproduce: For example nmcli c down 'cloud-init eth0'; nmcli c up 'cloud-init eth0' Cockpit's tests see this all over the place: https://cockpit-logs.us-east-1.linodeobjects.com/pull-17690-20220831-051933-cb3b0276-fedora-37/log.html
With full auditing enabled: ---- type=PROCTITLE msg=audit(08/31/2022 13:10:27.678:197) : proctitle=mv /run/console-login-helper-messages/console-login-helper-messages.KH6oQ7NMQO.tmp /etc/issue.d/22_clhm_eth0.issue type=PATH msg=audit(08/31/2022 13:10:27.678:197) : item=0 name=(null) inode=1171 dev=00:1a mode=file,644 ouid=root ogid=root rdev=00:00 obj=system_u:object_r:NetworkManager_dispatcher_console_var_run_t:s0 nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 type=CWD msg=audit(08/31/2022 13:10:27.678:197) : cwd=/ type=SYSCALL msg=audit(08/31/2022 13:10:27.678:197) : arch=x86_64 syscall=flistxattr success=yes exit=17 a0=0x3 a1=0x7ffe81308900 a2=0x11 a3=0x7ffe813099c1 items=1 ppid=838 pid=847 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=mv exe=/usr/bin/mv subj=system_u:system_r:NetworkManager_dispatcher_console_t:s0 key=(null) type=AVC msg=audit(08/31/2022 13:10:27.678:197) : avc: denied { sys_admin } for pid=847 comm=mv capability=sys_admin scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tcontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 tclass=capability permissive=0
(In reply to Zdenek Pytela from https://bugzilla.redhat.com/show_bug.cgi?id=2083900#c20) > ---- > type=PROCTITLE msg=audit(08/31/2022 13:10:27.678:197) : proctitle=mv > /run/console-login-helper-messages/console-login-helper-messages.KH6oQ7NMQO. > tmp /etc/issue.d/22_clhm_eth0.issue > type=PATH msg=audit(08/31/2022 13:10:27.678:197) : item=0 name=(null) > inode=1171 dev=00:1a mode=file,644 ouid=root ogid=root rdev=00:00 > obj=system_u:object_r:NetworkManager_dispatcher_console_var_run_t:s0 > nametype=NORMAL cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 > type=CWD msg=audit(08/31/2022 13:10:27.678:197) : cwd=/ > type=SYSCALL msg=audit(08/31/2022 13:10:27.678:197) : arch=x86_64 > syscall=flistxattr success=yes exit=17 a0=0x3 a1=0x7ffe81308900 a2=0x11 > a3=0x7ffe813099c1 items=1 ppid=838 pid=847 auid=unset uid=root gid=root > euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) > ses=unset comm=mv exe=/usr/bin/mv > subj=system_u:system_r:NetworkManager_dispatcher_console_t:s0 key=(null) > type=AVC msg=audit(08/31/2022 13:10:27.678:197) : avc: denied { sys_admin > } for pid=847 comm=mv capability=sys_admin > scontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 > tcontext=system_u:system_r:NetworkManager_dispatcher_console_t:s0 > tclass=capability permissive=0 > > Ondrej, > > CAP_SYS_ADMIN is needed for > > * perform operations on trusted and security extended > attributes (see > xattr(7)); > > Does flistxattr() really require this capability? It is required it only if the file has any trusted.* xattrs set and the caller expects to see them. However, currently for at least some filesystems the kernel will always do the check of CAP_SYS_ADMIN even if there are no such xattrs on the file. See e.g. [1]; other filesystems usually implement this logic on their own and may or may not have this annoying behavior. For example xfs does this the better way [2]. In this case the filesystem is most likely tmpfs, which AFAIK uses the problematic simple_xattr_list(). It seems that the right way to fix this is to modify simple_xattr_list() to call capable(CAP_SYS_ADMIN) only when there are actually any trusted.* xattrs, so I'm reassigning the bug to kernel/myself. [1] https://elixir.bootlin.com/linux/v5.19.5/source/fs/xattr.c#L1139 [2] https://elixir.bootlin.com/linux/v5.19.5/source/fs/xfs/xfs_xattr.c#L262
I posted patches upstream to fix this: https://lore.kernel.org/linux-fsdevel/20220901152632.970018-1-omosnace@redhat.com/T/
This now also slipped into Fedora 36
After some discussion upstream we came up with a different fix: https://lore.kernel.org/linux-fsdevel/20221103151205.702826-1-omosnace@redhat.com/T/
This should now be fixed in Rawhide since kernel-6.2.0-0.rc1.14.fc38 and in 37/36 since kernel kernel-6.0.16-200.fc37/.fc36.
Forgot to link the kernel commit: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=e7eda157c4071cd1e69f4b1687b0fbe1ae5e6f46