Bug 1933437 - SELinux is preventing mandb from using the 'fowner' capabilities.
Summary: SELinux is preventing mandb from using the 'fowner' capabilities.
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:5f7ce70f6e4c9eb050450b647f9...
: 1934756 1935562 1941671 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-02-27 20:17 UTC by Patrick Vavrina
Modified: 2023-09-15 01:33 UTC (History)
10 users (show)

Fixed In Version: selinux-policy-3.14.7-28.fc34
Clone Of:
Environment:
Last Closed: 2021-03-29 00:17:00 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Patrick Vavrina 2021-02-27 20:17:39 UTC
Description of problem:
SELinux is preventing mandb from using the 'fowner' capabilities.

*****  Plugin catchall (100. confidence) suggests   **************************

Si vous pensez que mandb devrait avoir des capacités fowner par défaut.
Then vous devriez rapporter ceci en tant qu'anomalie.
Vous pouvez générer un module de stratégie local pour autoriser cet accès.
Do
autoriser cet accès pour le moment en exécutant :
# ausearch -c "mandb" --raw | audit2allow -M my-mandb
# semodule -X 300 -i my-mandb.pp

Additional Information:
Source Context                system_u:system_r:mandb_t:s0
Target Context                system_u:system_r:mandb_t:s0
Target Objects                Inconnu [ capability ]
Source                        mandb
Source Path                   mandb
Port                          <Inconnu>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-3.14.8-4.fc35.noarch
Local Policy RPM              selinux-policy-targeted-3.14.8-4.fc35.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.12.0-0.rc0.20210225gitc03c21ba6f
                              4e.160.fc35.x86_64 #1 SMP Thu Feb 25 16:16:48 UTC
                              2021 x86_64 x86_64
Alert Count                   182
First Seen                    2021-02-27 21:15:23 CET
Last Seen                     2021-02-27 21:15:39 CET
Local ID                      7481cbbf-7c61-4fdf-818e-8e61751ab086

Raw Audit Messages
type=AVC msg=audit(1614456939.234:1112): avc:  denied  { fowner } for  pid=3402 comm="mandb" capability=3  scontext=system_u:system_r:mandb_t:s0 tcontext=system_u:system_r:mandb_t:s0 tclass=capability permissive=0


Hash: mandb,mandb_t,mandb_t,capability,fowner

Version-Release number of selected component:
selinux-policy-targeted-3.14.8-4.fc35.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.14.0
hashmarkername: setroubleshoot
kernel:         5.12.0-0.rc0.20210225gitc03c21ba6f4e.160.fc35.x86_64
type:           libreport

Comment 1 Zdenek Pytela 2021-03-01 18:18:59 UTC
Patrick,

The mandb_t domain is allowed the fsetid capability already, but not fowner. Can you isolate the process and the file which is to be changed ownership?

To have the filename audited, we need full auditing enabled.

1) Open the /etc/audit/rules.d/audit.rules file in an editor.
2) Remove the following line if it exists:
-a task,never
3) Add the following line to the end of the file:
-w /etc/shadow -p w
4) Restart the audit daemon:
  # service auditd restart
5) Re-run your scenario.
6) Collect AVC denials:
  # ausearch -i -m avc,user_avc,selinux_err,user_selinux_err -ts today

Comment 2 Patrick Vavrina 2021-03-06 01:05:28 UTC
----
type=AVC msg=audit(06. 03. 21 00:39:43.681:1160) : avc:  denied  { fowner } for  pid=31363 comm=mandb capability=fowner  scontext=system_u:system_r:mandb_t:s0 tcontext=system_u:system_r:mandb_t:s0 tclass=capability permissive=0 
----
type=AVC msg=audit(06. 03. 21 00:39:43.681:1161) : avc:  denied  { fowner } for  pid=31363 comm=mandb capability=fowner  scontext=system_u:system_r:mandb_t:s0 tcontext=system_u:system_r:mandb_t:s0 tclass=capability permissive=0 
----
type=AVC msg=audit(06. 03. 21 01:30:26.546:1399) : avc:  denied  { fowner } for  pid=37579 comm=systemd-coredum capability=fowner  scontext=system_u:system_r:systemd_coredump_t:s0 tcontext=system_u:system_r:systemd_coredump_t:s0 tclass=capability permissive=0

Comment 3 Zdenek Pytela 2021-03-19 15:42:14 UTC
Patrick,

There seems to be a problem with XFS and new kernels. Could you try an older kernel, preferably from 5.11 series?

Comment 4 Zdenek Pytela 2021-03-23 16:52:52 UTC
This is supposed to be a bug in kernel/xfs. A patch has been sent to address it:
https://lore.kernel.org/linux-xfs/20210316173226.2220046-1-omosnace@redhat.com/T/

However, as the proper kernel fix can take time, it will be temporarily worked around in the selinux policy not to trigger false AVC denials.

Comment 5 Zdenek Pytela 2021-03-23 17:05:22 UTC
*** Bug 1934756 has been marked as a duplicate of this bug. ***

Comment 6 Zdenek Pytela 2021-03-23 17:05:35 UTC
*** Bug 1935562 has been marked as a duplicate of this bug. ***

Comment 7 Zdenek Pytela 2021-03-23 17:05:45 UTC
*** Bug 1941671 has been marked as a duplicate of this bug. ***

Comment 8 Zdenek Pytela 2021-03-23 17:11:11 UTC
Resolved in rawhide:
commit bca021fb2bdd1ff12313f1273ffa0c9d03befa3c (HEAD -> rawhide, upstream/rawhide, upstream-rw/rawhide, origin/rawhide, origin/HEAD)
Author: Zdenek Pytela <zpytela>
Date:   Tue Mar 23 17:23:44 2021 +0100

    Dontaudit domain the fowner capability

    This is a temporary rule to work around a problem in kernel/xfs
    triggering a false fowner capability AVC. Once the problem is resolved,
    this commit needs to be reverted.

    Resolves: rhbz#1933437

Comment 9 Fedora Update System 2021-03-24 18:03:04 UTC
FEDORA-2021-68c09eb43f has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-68c09eb43f

Comment 10 Fedora Update System 2021-03-25 01:24:29 UTC
FEDORA-2021-68c09eb43f has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-68c09eb43f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-68c09eb43f

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 11 Fedora Update System 2021-03-27 02:01:10 UTC
FEDORA-2021-15b81d905c has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-15b81d905c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-15b81d905c

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Comment 12 Fedora Update System 2021-03-29 00:17:00 UTC
FEDORA-2021-15b81d905c has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 13 Eric Sandeen 2022-07-21 14:25:45 UTC
FYI:

This has been resolved in xfs as of kernel v5.18, with commit:

commit eba0549bc7d100691c13384b774346b8aa9cf9a9
Author: Darrick J. Wong <djwong>
Date:   Fri Feb 25 16:18:30 2022 -0800

    xfs: don't generate selinux audit messages for capability testing

so this change can be reverted in at least rawhide now, what do you think?

-Eric

Comment 14 Zdenek Pytela 2022-08-02 09:19:26 UTC
Thank you Eric for letting me know.

https://github.com/fedora-selinux/selinux-policy/pull/1301

Comment 15 Red Hat Bugzilla 2023-09-15 01:33:00 UTC
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 365 days


Note You need to log in before you can comment on or make changes to this bug.