Bug 2134044 - SELinux is preventing waydroid from 'search' accesses on the Verzeichnis /var/lib/snapd.
Summary: SELinux is preventing waydroid from 'search' accesses on the Verzeichnis /var...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: waydroid
Version: 38
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Alessandro Astone
QA Contact:
URL:
Whiteboard: abrt_hash:3f381e192e46d2ddd4dd0c58b57...
: 2144260 2188420 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2022-10-12 08:29 UTC by aannoaanno
Modified: 2023-11-03 18:23 UTC (History)
9 users (show)

Fixed In Version: waydroid-1.4.1-3.fc38 waydroid-1.4.1-3.fc39
Clone Of:
Environment:
Last Closed: 2023-10-04 15:50:30 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description aannoaanno 2022-10-12 08:29:36 UTC
Description of problem:
SELinux is preventing waydroid from 'search' accesses on the Verzeichnis /var/lib/snapd.

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

Wenn Sie denken, dass es waydroid standardmäßig erlaubt sein sollte, search Zugriff auf snapd directory zu erhalten.
Then sie sollten dies als Fehler melden.
Um diesen Zugriff zu erlauben, können Sie ein lokales Richtlinien-Modul erstellen.
Do
zugriff jetzt erlauben, indem Sie die nachfolgenden Befehle ausführen:
# ausearch -c 'waydroid' --raw | audit2allow -M my-waydroid
# semodule -X 300 -i my-waydroid.pp

Additional Information:
Source Context                system_u:system_r:waydroid_t:s0
Target Context                system_u:object_r:snappy_var_lib_t:s0
Target Objects                /var/lib/snapd [ dir ]
Source                        waydroid
Source Path                   waydroid
Port                          <Unbekannt>
Host                          (removed)
Source RPM Packages           
Target RPM Packages           snapd-2.56.2-4.fc36.x86_64
SELinux Policy RPM            selinux-policy-targeted-36.15-1.fc36.noarch
Local Policy RPM              
Selinux Enabled               True
Policy Type                   targeted
Enforcing Mode                Enforcing
Host Name                     (removed)
Platform                      Linux (removed) 5.19.14-200.fc36.x86_64 #1 SMP
                              PREEMPT_DYNAMIC Wed Oct 5 21:31:17 UTC 2022 x86_64
                              x86_64
Alert Count                   14
First Seen                    2022-10-11 14:53:13 CEST
Last Seen                     2022-10-12 10:26:14 CEST
Local ID                      b66ae310-136a-4292-8341-91528f0caca5

Raw Audit Messages
type=AVC msg=audit(1665563174.123:238): avc:  denied  { search } for  pid=1875 comm="waydroid" name="snapd" dev="dm-1" ino=3092727 scontext=system_u:system_r:waydroid_t:s0 tcontext=system_u:object_r:snappy_var_lib_t:s0 tclass=dir permissive=0


Hash: waydroid,waydroid_t,snappy_var_lib_t,dir,search

Version-Release number of selected component:
selinux-policy-targeted-36.15-1.fc36.noarch

Additional info:
component:      selinux-policy
reporter:       libreport-2.17.4
hashmarkername: setroubleshoot
kernel:         5.19.14-200.fc36.x86_64
type:           libreport

Comment 1 Alessandro Astone 2023-01-03 13:23:39 UTC
*** Bug 2144260 has been marked as a duplicate of this bug. ***

Comment 2 Alessandro Astone 2023-01-03 13:36:43 UTC
I'm not sure how to deal with this.
It is caused by python `shutil.which` searching $PATH that includes /var/lib/snapd/snap/bin when snapd is installed. Naturally it is harmless as waydroid_t is not meant to use snap in any way.
The issue is I cannot just `dontaudit` it because snappy_var_lib_t is only defined if snapd-selinux.noarch is installed.

I see mandb_t has a similar thing and it is handled in snapd's sepolicy itself: https://github.com/snapcore/snapd/blob/master/data/selinux/snappy.te#L914
There they can rely on mandb_t being defined in the common sepolicy. My sepolicy is instead a self contained module, just like snapd-selinux.noarch, so neither can depend on either.
Anyone has thoughts on what to do? Is there no way to make a sepolicy statement optional depending on whether the target context is defined or not?

Comment 3 Alessandro Astone 2023-04-20 18:07:33 UTC
*** Bug 2188420 has been marked as a duplicate of this bug. ***

Comment 4 Ben Cotton 2023-04-25 18:03:36 UTC
This message is a reminder that Fedora Linux 36 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora Linux 36 on 2023-05-16.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
'version' of '36'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, change the 'version' 
to a later Fedora Linux version. Note that the version field may be hidden.
Click the "Show advanced fields" button if you do not see it.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora Linux 36 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora Linux, you are encouraged to change the 'version' to a later version
prior to this bug being closed.

Comment 5 Milos Malik 2023-09-26 07:52:20 UTC
# rpm -qa | grep -e snapd -e waydroid | sort
snapd-2.58.3-2.fc39.x86_64
snapd-selinux-2.58.3-2.fc39.noarch
waydroid-1.4.1-2.fc39.noarch
waydroid-selinux-1.4.1-2.fc39.noarch
# service waydroid-container restart
Redirecting to /bin/systemctl restart waydroid-container.service
#

The following SELinux denial appears in enforcing mode:
----
type=PROCTITLE msg=audit(09/26/2023 03:43:09.971:201) : proctitle=/usr/bin/python3 /usr/bin/waydroid -w container start 
type=PATH msg=audit(09/26/2023 03:43:09.971:201) : item=0 name=/var/lib/snapd/snap/bin/xclip nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(09/26/2023 03:43:09.971:201) : cwd=/ 
type=SYSCALL msg=audit(09/26/2023 03:43:09.971:201) : arch=x86_64 syscall=newfstatat success=no exit=EACCES(Permission denied) a0=AT_FDCWD a1=0x7ff8a6bd6bd0 a2=0x7ffd5ed34e10 a3=0x0 items=1 ppid=1 pid=1588 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=waydroid exe=/usr/bin/python3.12 subj=system_u:system_r:waydroid_t:s0 key=(null) 
type=AVC msg=audit(09/26/2023 03:43:09.971:201) : avc:  denied  { search } for  pid=1588 comm=waydroid name=snapd dev="vda2" ino=267316 scontext=system_u:system_r:waydroid_t:s0 tcontext=system_u:object_r:snappy_var_lib_t:s0 tclass=dir permissive=0 
----

The following SELinux denial appears in permissive mode:
----
type=PROCTITLE msg=audit(09/26/2023 03:44:40.013:206) : proctitle=/usr/bin/python3 /usr/bin/waydroid -w container start 
type=PATH msg=audit(09/26/2023 03:44:40.013:206) : item=0 name=/var/lib/snapd/snap/bin/xclip nametype=UNKNOWN cap_fp=none cap_fi=none cap_fe=0 cap_fver=0 cap_frootid=0 
type=CWD msg=audit(09/26/2023 03:44:40.013:206) : cwd=/ 
type=SYSCALL msg=audit(09/26/2023 03:44:40.013:206) : arch=x86_64 syscall=newfstatat success=no exit=ENOENT(No such file or directory) a0=AT_FDCWD a1=0x7fa7eda37d50 a2=0x7ffcad07cb10 a3=0x0 items=1 ppid=1 pid=1599 auid=unset uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root tty=(none) ses=unset comm=waydroid exe=/usr/bin/python3.12 subj=system_u:system_r:waydroid_t:s0 key=(null) 
type=AVC msg=audit(09/26/2023 03:44:40.013:206) : avc:  denied  { search } for  pid=1599 comm=waydroid name=snapd dev="vda2" ino=267316 scontext=system_u:system_r:waydroid_t:s0 tcontext=system_u:object_r:snappy_var_lib_t:s0 tclass=dir permissive=1 
----

# ausearch -m avc -m user_avc -i -m selinux_err | audit2allow -R

require {
	type waydroid_t;
}

#============= waydroid_t ==============
snappy_search_lib(waydroid_t)

#

I believe that optional_policy block is a good way how to solve the situation:
 * https://mgrepl.wordpress.com/2011/12/04/troubles-with-policy-development-part-1/

Comment 6 Alessandro Astone 2023-09-26 08:02:21 UTC
Thanks! Optional policy seems to be what I was looking for

Comment 7 Fedora Update System 2023-09-26 12:29:42 UTC
FEDORA-2023-29eea4d76b has been submitted as an update to Fedora 38. https://bodhi.fedoraproject.org/updates/FEDORA-2023-29eea4d76b

Comment 8 Fedora Update System 2023-09-26 12:29:43 UTC
FEDORA-2023-5a09b5def9 has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2023-5a09b5def9

Comment 9 Fedora Update System 2023-09-27 01:25:45 UTC
FEDORA-2023-5a09b5def9 has been pushed to the Fedora 39 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-5a09b5def9`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-5a09b5def9

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

Comment 10 Fedora Update System 2023-09-27 01:35:47 UTC
FEDORA-2023-29eea4d76b has been pushed to the Fedora 38 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2023-29eea4d76b`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2023-29eea4d76b

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

Comment 11 Fedora Update System 2023-10-04 15:50:30 UTC
FEDORA-2023-29eea4d76b has been pushed to the Fedora 38 stable repository.
If problem still persists, please make note of it in this bug report.

Comment 12 Fedora Update System 2023-11-03 18:23:07 UTC
FEDORA-2023-5a09b5def9 has been pushed to the Fedora 39 stable repository.
If problem still persists, please make note of it in this bug report.


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