Bug 2248830

Hi Marek,

I managed to make a progress for the first 2 issues and rpcbind.
For dovecot_auth a setup which triggers the denial would be helpful.
For mariadb please gather the denials in permissive mode.

Created attachment 1999189 [details]
Additional debug on rpcbind

Additional debug on rpcbind. Several other blockings appeared after enabling permissive mode.

Hello,

I enabled permissive mode and enabled debugs to catch the mariadb issue. It still did not trigger, but the rpcbind issue hits more blockings after enabling permissive mode, so I attached it. I will attach also mariadb blockings when they appear.

Regarding dovecot auth issue. I am not sure which details on setup are relevant. Dovecot is configured to authenticate users using gssapi and also plain and login. Users use imap protocol to connect to dovecot.  The gssapi authenticated users (the most ones) do not trigger the issue. Please specify which details are you interested in. Some configuration file snippets are required?

Thanks

Marek

Created attachment 1999252 [details]
Spamassassin and mimendefang related blockings

Hello,

I am still unable to reproduce the mariadb blockings but when running strings /usr/sbin/mariadbd | grep /proc I get:

/proc/self/cwd
/proc/self/limits
/proc/sys/kernel/core_pattern
/proc/version

So probable access to these files yielded the blocking.

Marek

Hello,

it seems like this blocking:

type=AVC msg=audit(09.11.2023 09:03:47.443:974) : avc:  denied  { unlink } for  pid=5200 comm=(sd-rmrf) name=krb5_97.rcache2 dev="dm-2" ino=1179664 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:dovecot_auth_tmp_t:s0 tclass=file permissive=0 

was fixed in selinux-policy-39.2-1.fc39.noarch.

M.

Same for rpcbind.

Marek

If I read this correctly, there are 2 outstanding problems:
- mariadb reading something in /proc/sys/net, reproducer is unknown

- nfsd lease, a kernel trace would be helpful
https://fedoraproject.org/wiki/SELinux/Debugging#Using_tracefs

Hello,

nearly true. There is outstanding problem with mariadb which I cannot reproduce any more, outstanding problem with nfsd (did not I attach kernel trace in the bug 2216408? it is the same issue), the dovecot plain auth problem and additionaly reported spamassassin problem which arised after enabling permissive mode to catch the mariadb issue (do you recommend to open separate bug report for it?).

Thanks

Marek

Created attachment 2000960 [details]
Fresh nfsd trace

Fresh nfsd trace.

Marek, thank you for the rpc.nfsd kernel trace - that helped me get closer to the root cause. (The kernel trace in bug 2216408#c8 was from a different denial.)

Comparing the trace with the kernel source code, it appears to be from kernel 6.5.x (or earlier), where I can see a path where the capability may be incorrectly checked against a process writing into /proc/fs/nfsd/threads (rpc.nfsd in this case). However, in kernel 6.6 there was some refactoring around nfsd_put(), which looks like it may have fixed this problem. Could you please try to reproduce the "denied { lease }" denial with kernel 6.6.x? This version has not yet been pushed to Fedora 39, but you can follow the Kernel Test Day instructions [1] to install a testing build from COPR or Koji.

[1] https://fedoraproject.org/wiki/Test_Day:2023-11-12_Kernel_6.6_Test_Week#Prerequisite_for_Test_Day

Hello Ondrej,

thank you very much for good news. Since it is a cosmetic issue and the kernel 6.6 is going to be an update soon, I will report success right after I test the new kernel.

Marek

Created attachment 2001136 [details]
Blockings on dovecot plain auth

I attach fresh blocking for dovecot plain auth.

I created separate bug report for spamassassin related blockings.

Hello,

unfortunately the rpc.nfsd problem is not fixed using kernel-6.6.2:

type=PROCTITLE msg=audit(29.11.2023 07:43:04.885:439) : proctitle=/usr/sbin/rpc.
nfsd 0 
type=SYSCALL msg=audit(29.11.2023 07:43:04.885:439) : arch=x86_64 syscall=write 
success=yes exit=2 a0=0x3 a1=0x5600ff07fc60 a2=0x2 a3=0x0 items=0 ppid=1 pid=990
7 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=roo
t fsgid=root tty=(none) ses=unset comm=rpc.nfsd exe=/usr/sbin/rpc.nfsd subj=syst
em_u:system_r:nfsd_t:s0 key=(null) 
type=AVC msg=audit(29.11.2023 07:43:04.885:439) : avc:  denied  { lease } for  pid=9907 comm=rpc.nfsd capability=lease  scontext=system_u:system_r:nfsd_t:s0 tcontext=system_u:system_r:nfsd_t:s0 tclass=capability permissive=1 

Marek

Created attachment 2001940 [details]
rpc.nfsd kernel trace

Hello Ondrej,

do you have any other thoughts when could be the root cause of the nfsd blockings?

Thanks

Marek

Sorry for the late follow-up... I have reported the issue to the relevant kernel mailing lists [1], as I'm not sure how to fix it. Hopefully the NFS / general filesystem developers will be able to come up with something.

[1] https://lore.kernel.org/linux-nfs/CAFqZXNu2V-zV2UHk5006mw8mjURdFmD-74edBeo-7ZX5LJNXag@mail.gmail.com/T/#u

Thanks, Ondrej.

Marek

And actually there is a fix in linux-next [1] now, which means it will be fixed in kernel 6.9+. It won't get fixed in earlier stable versions unless someone follows [2] to get the fix backported. But since it can be easily worked around, I think it's not necessary.

(BTW, Jeff mistakenly put Zdenek as the reporter, but it's probably too late to fix that now.)

[1] https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/commit/?id=7b8001013d720c232ad9ae7aae0ef0e7c281c6d4
[2] https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html

Great new, Ondrej. No problem to wait for 6.9.

Marek

Hello Ondrej,

I confirm the messages are gone with kernel-6.9.4-200.fc40.x86_64. I created separate bug for the other issues, so you can close the case.

Thanks

Marek