Bug 1835952 - SELinux is preventing systemd-user-ru from 'setattr' accesses on the fichier reg.
Summary: SELinux is preventing systemd-user-ru from 'setattr' accesses on the fichier ...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 32
Hardware: x86_64
OS: Unspecified
medium
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard: abrt_hash:4f540bc3daaeb2647f4217c1ed8...
Depends On: 1812955
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-05-14 19:20 UTC by Benjamin Masse
Modified: 2020-05-20 06:06 UTC (History)
6 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2020-05-20 06:06:12 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Benjamin Masse 2020-05-14 19:20:47 UTC
Description of problem:
SELinux is preventing systemd-user-ru from 'setattr' accesses on the fichier reg.

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

Si vous pensez que systemd-user-ru devrait être autorisé à accéder setattr sur reg file 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 "systemd-user-ru" --raw | audit2allow -M my-systemduserru
# semodule -X 300 -i my-systemduserru.pp

Additional Information:
Source Context                system_u:system_r:init_t:s0
Target Context                system_u:object_r:user_tmp_t:s0
Target Objects                reg [ file ]
Source                        systemd-user-ru
Source Path                   systemd-user-ru
Port                          <Inconnu>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           
SELinux Policy RPM            selinux-policy-targeted-3.14.5-38.fc32.noarch
Local Policy RPM              selinux-policy-targeted-3.14.5-38.fc32.noarch
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Permissive
Host Name                     (removed)
Platform                      Linux (removed) 5.6.11-300.fc32.x86_64 #1 SMP Wed
                              May 6 19:12:19 UTC 2020 x86_64 x86_64
Alert Count                   2
First Seen                    2020-05-14 21:16:12 CEST
Last Seen                     2020-05-14 21:16:30 CEST
Local ID                      1e83c7df-c3d3-4305-9a5c-891d7a2a2cbe

Raw Audit Messages
type=AVC msg=audit(1589483790.268:285): avc:  denied  { setattr } for  pid=2867 comm="systemd-user-ru" name="reg" dev="tmpfs" ino=70354 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:user_tmp_t:s0 tclass=file permissive=1


Hash: systemd-user-ru,init_t,user_tmp_t,file,setattr

Version-Release number of selected component:
selinux-policy-targeted-3.14.5-38.fc32.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.12.0
hashmarkername: setroubleshoot
kernel:         5.6.11-300.fc32.x86_64
type:           libreport

Comment 1 Zdenek Pytela 2020-05-15 07:09:58 UTC
Hi,

The dac_override permission is requested on an access attempt where DAC permission do not allow this access, the file path is not audited though. Please follow the recommendations of the restorecon plugin to turn on full auditing and when reproduced again, check permissions for the file or directory.

How to enable full auditing in audit daemon:

1) Open /etc/audit/rules.d/audit.rules file in an editor.
2) Remove following line if it exists:
-a task,never
3) Add following line at 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 Zdenek Pytela 2020-05-15 07:15:15 UTC
Benjamin,

Please disregard the previous comment, dac_override is not in place in this report. The steps for enabling full auditing are valid, we can disclose the file path for the setattr permission, too.

Comment 3 Benjamin Masse 2020-05-20 06:06:12 UTC
Hi Zdenek.

A relabelling and reboot solved the issue.
I'm closing the request.

Thanks anyway and regards,

Benjamin


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