Bug 2188703 - SELinux block /usr/lib/systemd/systemd-resolved watch access in directory /
Summary: SELinux block /usr/lib/systemd/systemd-resolved watch access in directory /
Keywords:
Status: CLOSED INSUFFICIENT_DATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 37
Hardware: x86_64
OS: Linux
low
medium
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2023-04-21 18:38 UTC by Jakub Jankiewicz
Modified: 2023-06-27 19:01 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2023-06-27 19:01:06 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Jakub Jankiewicz 2023-04-21 18:38:27 UTC
Got this localized message from throbleshooter

SELinux powstrzymuje /usr/lib/systemd/systemd-resolved przed dostępem watch w katalog /.

*****  Wtyczka catchall_labels (83.8 zaufania) sugeruje   ********************

Aby zezwolić systemd-resolved na dostęp watch w  directory
Wtedy należy zmienić etykietę /
Wykonać
# semanage fcontext -a -t TYP_PLIKU '/',
gdzie TYP_PLIKU jest jednym z poniższych: init_var_run_t, root_t, system_dbusd_var_run_t, systemd_networkd_var_run_t, systemd_resolved_var_run_t, tmpfs_t, var_run_t.
Następnie należy wykonać polecenie:
restorecon -v '/'


*****  Wtyczka catchall (17.1 zaufania) sugeruje   ***************************

Aby systemd-resolved powinno mieć domyślnie watch dostęp do  directory.
Wtedy proszę to zgłosić jako błąd.
Można utworzyć lokalny moduł polityki, aby umożliwić ten dostęp.
Wykonać
można tymczasowo zezwolić na ten dostęp wykonując polecenia:
# ausearch -c 'systemd-resolve' --raw | audit2allow -M my-systemdresolve
# semodule -X 300 -i my-systemdresolve.pp

Dodatkowe informacje:
Kontekst źródłowy             system_u:system_r:systemd_resolved_t:s0
Kontekst docelowy             system_u:object_r:usr_t:s0
Obiekty docelowe              / [ dir ]
Źródło                        systemd-resolve
Ścieżka źródłowa              /usr/lib/systemd/systemd-resolved
Port                          <Nieznane>
Komputer                      jcubic
Źródłowe pakiety RPM          systemd-resolved-251.14-2.fc37.x86_64
Docelowe pakiety RPM          
Pakiet RPM polityki SELinuksa selinux-policy-targeted-37.19-1.fc37.noarch
Lokalny pakiet RPM polityki   selinux-policy-targeted-37.19-1.fc37.noarch
SELinux jest włączony         True
Typ polityki                  targeted
Tryb wymuszania               Permissive
Nazwa komputera               jcubic
Platforma                     Linux jcubic 6.2.10-200.fc37.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Thu Apr  6 23:30:41 UTC 2023
                              x86_64 x86_64
Liczba alarmów                1
Po raz pierwszy               2023-04-21 18:25:41 CEST
Po raz ostatni                2023-04-21 18:25:41 CEST
Lokalny identyfikator         35a097e2-a84b-4894-9c8a-1cb6d62c610b

Surowe komunikaty audytu
type=AVC msg=audit(1682094341.26:162): avc:  denied  { watch } for  pid=927 comm="systemd-resolve" path="/" dev="sda4" ino=2 scontext=system_u:system_r:systemd_resolved_t:s0 tcontext=system_u:object_r:usr_t:s0 tclass=dir permissive=1


type=SYSCALL msg=audit(1682094341.26:162): arch=x86_64 syscall=inotify_add_watch success=yes exit=EPERM a0=f a1=7f201a2a4962 a2=180 a3=7ffe11d5d6c4 items=1 ppid=1 pid=927 auid=4294967295 uid=193 gid=193 euid=193 suid=193 fsuid=193 egid=193 sgid=193 fsgid=193 tty=(none) ses=4294967295 comm=systemd-resolve exe=/usr/lib/systemd/systemd-resolved subj=system_u:system_r:systemd_resolved_t:s0 key=(null)

type=CWD msg=audit(1682094341.26:162): cwd=/

type=PATH msg=audit(1682094341.26:162): item=0 name=/ inode=2 dev=08:04 mode=040755 ouid=0 ogid=0 rdev=00:00 obj=system_u:object_r:usr_t:s0 nametype=NORMAL cap_fp=0 cap_fi=0 cap_fe=0 cap_fver=0 cap_frootid=0

Hash: systemd-resolve,systemd_resolved_t,usr_t,dir,watch


Reproducible: Didn't try




I have no idea what trigger this, after booting got this SELinux error.

Comment 1 Zdenek Pytela 2023-04-24 15:21:16 UTC
Hi Jakub,

It would be nice ifwe knew howto reproduce the issue. Still, can you gather some more details? What filesystem is on sda4? At which moment this issue happened? Can you pair the audit event with some journal logs data?

Comment 2 Jakub Jankiewicz 2023-04-24 15:53:36 UTC
Sorry I have no idea, I usually run my system for a long time, I've turned it off and run again after one day and got this in my notifications.

Comment 4 Zdenek Pytela 2023-06-27 19:01:06 UTC
As no new information appeared during the past weeks, we are going to close this bug. If you need to pursue this matter further, feel free to reopen this bug and attach the needed information.


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