I get this avc denial about once a day in my samba setup. I do not see any smb.conf tunables related to memory locking so I assume ipc_lock is a standard capability that smb needs and makes use of. Samba version: samba-4.18.2-0.fc38.x86_64 Policy version: selinux-policy-targeted-38.12-1.fc38.noarch -- SELinux is preventing smbd[19.19.19.2 from using the ipc_lock capability. ***** Plugin catchall (100. confidence) suggests ************************** If you believe that smbd[19.19.19.2 should have the ipc_lock capability by default. Then you should report this as a bug. You can generate a local policy module to allow this access. Do allow this access for now by executing: # ausearch -c 'smbd[19.19.19.2' --raw | audit2allow -M my-smbd1919192 # semodule -X 300 -i my-smbd1919192.pp Additional Information: Source Context system_u:system_r:smbd_t:s0 Target Context system_u:system_r:smbd_t:s0 Target Objects Unknown [ capability ] Source smbd[19.19.19.2 Source Path smbd[19.19.19.2 Port <Unknown> Host cipisrv Source RPM Packages Target RPM Packages SELinux Policy RPM selinux-policy-targeted-38.12-1.fc38.noarch Local Policy RPM selinux-policy-targeted-38.12-1.fc38.noarch Selinux Enabled True Policy Type targeted Enforcing Mode Permissive Host Name cipisrv Platform Linux cipisrv 6.2.13-300.fc38.x86_64 #1 SMP PREEMPT_DYNAMIC Thu Apr 27 01:33:30 UTC 2023 x86_64 Alert Count 9 First Seen 2023-05-02 21:43:44 MDT Last Seen 2023-05-05 00:01:31 MDT Local ID 4deb34b9-bd1e-44bf-aab4-76c1a1389790 Raw Audit Messages type=AVC msg=audit(1683266491.547:39585): avc: denied { ipc_lock } for pid=619022 comm="smbd[19.19.19.2" capability=14 scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:smbd_t:s0 tclass=capability permissive=1 Hash: smbd[19.19.19.2,smbd_t,smbd_t,capability,ipc_lock Reproducible: Always Steps to Reproduce: 1. Use smb for file sharing and wait. I can provide my smb.conf as an attachment if needed 2. 3. Actual Results: Daily avc denials about ipc_lock for the smb process Expected Results: No avc denial This has been happening since at least F37 where I coped with a custom policy module containing "allow smbd_t self:capability ipc_lock;", but I decided to file the bug now as it still occurs in F38
Matt, Please provide the configuration changes and usage needed to trigger this issue.
Apologies for the late response. I have traced the issue to the vfs "io_uring" module and have a simple reproducer. On a fresh F38 Server vm: 1. dnf install samba samba-vfs-iouring 2. mkdir /srv/share1 && chmod 777 /srv/share1 3. semanage fcontext -a -t samba_share_t '/srv(/.*)' && restorecon /srv/share1 4. In /etc/samba/smb.conf: [global] workgroup = SAMBA security = user passdb backend = tdbsam server multi channel support = no server smb encrypt = desired vfs objects = streams_xattr io_uring [share1] path = /srv/share1 available = yes browseable = yes read only = no 5. systemctl start smb 6. On the same machine, the avc denial can be caused by doing any of the following: smbclient -L \\\\localhost smbclient \\\\localhost\\share1 trying to access the share via file manager with smb://localhost/share1 The above commands do not even need to succeed for the avc denial to be generated. Removing "io_uring" from vfs objects stops the issue.
Thank you, the reproducer works and we can see more information: ---- type=PROCTITLE msg=audit(05/24/2023 09:56:47.827:259) : proctitle=/usr/sbin/smbd --foreground --no-process-group type=SYSCALL msg=audit(05/24/2023 09:56:47.827:259) : arch=x86_64 syscall=io_uring_setup success=yes exit=9 a0=0x80 a1=0x7ffcf5e3fc90 a2=0x7ffcf5e3fc90 a3=0x0 items=0 ppid=5756 pid=6459 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=smbd[127.0.0.1] exe=/usr/sbin/smbd subj=system_u:system_r:smbd_t:s0 key=(null) type=AVC msg=audit(05/24/2023 09:56:47.827:259) : avc: denied { ipc_lock } for pid=6459 comm=smbd[127.0.0.1] capability=ipc_lock scontext=system_u:system_r:smbd_t:s0 tcontext=system_u:system_r:smbd_t:s0 tclass=capability permissive=0 smbd[127.0.0.1] 6459 [000] 4603.537095: avc:selinux_audited: requested=0x4000 denied=0x4000 audi> BFD: DWARF error: could not find variable specification at offset 0x1bfd7 BFD: DWARF error: could not find variable specification at offset 0x1bfe0 BFD: DWARF error: could not find variable specification at offset 0x1bfec BFD: DWARF error: could not find variable specification at offset 0x1bff8 BFD: DWARF error: could not find variable specification at offset 0x1b551 BFD: DWARF error: could not find variable specification at offset 0x18a5c BFD: DWARF error: could not find variable specification at offset 0x1de94 BFD: DWARF error: could not find variable specification at offset 0x1de9e BFD: DWARF error: could not find variable specification at offset 0x1dea9 ffffffffae6d6831 avc_audit_post_callback+0x211 ([kernel.kallsyms]) ffffffffae6d6831 avc_audit_post_callback+0x211 ([kernel.kallsyms]) ffffffffae6ff5be common_lsm_audit+0x2ae ([kernel.kallsyms]) ffffffffae6d7aba slow_avc_audit+0xca ([kernel.kallsyms]) ffffffffae6dcdbe cred_has_capability.isra.0+0x12e ([kernel.kallsyms]) ffffffffae6d1390 security_capable+0x40 ([kernel.kallsyms]) ffffffffae11b84b capable+0x2b ([kernel.kallsyms]) ffffffffae7b8063 io_uring_setup+0x483 ([kernel.kallsyms]) ffffffffaef6018c do_syscall_64+0x5c ([kernel.kallsyms]) ffffffffaf0000aa entry_SYSCALL_64_after_hwframe+0x72 ([kernel.kallsyms]) 258c io_uring_queue_init_params+0x1b (/usr/lib64/liburing.so.2.3) 2618 io_uring_queue_init+0x3a (/usr/lib64/liburing.so.2.3) 2f9a vfs_io_uring_connect+0xda (/usr/lib64/samba/vfs/io_uring.so) 6509 streams_xattr_connect+0x19 (/usr/lib64/samba/vfs/streams_xattr.so)
The relevant code is: ctx->compat = in_compat_syscall(); if (!capable(CAP_IPC_LOCK)) ctx->user = get_uid(current_user()); ...which looks like a candidate for ns_capable_noaudit(). (If the capability is not granted, the code just takes a different path and doesn't fail because of it. Thus the capability should be silently tested with no audit record when it is denied.) Switching to the kernel and will send a patch upstream later...
https://lore.kernel.org/io-uring/20230718115607.65652-1-omosnace@redhat.com/
This should be fixed in F38 as of kernel-6.4.8-200.fc38. The mainline commit is: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6adc2272aaaf84f34b652cf77f770c6fcc4b8336