Flatpak have developed a lot recently and it seems to need access to many resources which are not shared with all processes. It seems there is the need now to have it confined. This bug was initially created as a copy of Bug #2001837 Description of problem: On Fedora 35 Beta, the g-i-s provides a screen where Fedora Third Party repositories can be switched on, however when this screen is used to switch on the Third Party repos, they remain switched off in Software which also suggests to switch them on. Version-Release number of selected component (if applicable): gnome-session-40.1.1-2.fc35.x86_64 gnome-initial-setup-41~beta-3.fc35.x86_64 gnome-software-41~beta-3.fc35.x86_64 How reproducible: Always Steps to Reproduce: 1. Fresh install Fedora Workstation 35 and wait until g-i-s starts (it can take upto 2 minutes). 2. Create the username and password. 3. Switch on the Fedora Third Party repos and finish the wizard. 4. Open Software and check if Third Party repos are switched on -> they are not. Actual results: Gnome Initial Setup cannot switch the Third party repos on. Expected results: If such option is there, Gnome initial setup should be able to use it.
I'll be happy to create the policy for flatpak. However, I am not fully aware of how flatpak works and am unable to assess the impact of the changes proposed. How can I check the basic functionality? I see a tests/ directory in the github repo - can these scripts be used?
Can we figure out something temporarily for Fedora 35 - trying to comprehensively create a selinux policy for Flatpak seems unrealistic for Fedora 35 GA, and likely to create regressions, but we really need to get a simple policy in place that allows fedora-third-party running under gnome-initia-setup to call flatpak to add a repository. Can we just add the permissions detailed in the other bug to fedora-third-party policy? https://bugzilla.redhat.com/show_bug.cgi?id=2001837#c54
I've submitted a PR to make f-t-p working, but I think there still is a need to confine flatpak. I already have a patch set working during the installation, but I cannot confirm if flatpak and other application needing it will work correctly later.
Hmm, we still have some issues. Trying it out, I get, in addition to the setsched/sys_nice audit messages we are ignoring: === type=AVC msg=audit(1634569129.980:219): avc: denied { read write } for pid=1603 comm="gpg" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclass= chr_file permissive=0 type=AVC msg=audit(1634569129.988:220): avc: denied { read write } for pid=1605 comm="gpgsm" path="/dev/tty1" dev="devtmpfs" ino=20 scontext=system_u:system_r:gpg_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tty_device_t:s0 tclas s=chr_file permissive=0 type=AVC msg=audit(1634569129.993:221): avc: denied { create } for pid=1595 comm="flatpak" name="ostree-gpg-1Fze82" scontext=system_u:system_r:fedoratp_t:s0-s0:c0.c1023 tcontext=system_u:object_r:tmp_t:s0 tclass=dir permissive=0 === The first two I don't think the are problematical and seem to not always appear - but the third is causing flatpak to exit with an exit code of 1, and fedora-third-party to crash. This probably got hidden in testing earlier because with the crash at this point * flatpak has created the remote * fedora-third-party hasn't recorded that flatpak created the remote on fedora-third-parties behalf and will not remove it on 'fedora-third-party disable' * on the next testing run, since the remote already exists, it will not be created So the reset procedure needs an explicit "flatpak remote-delete flathub" I also think selinux is also causing the stdout/stderr of fedora-third-party not to end up in the system log as you'd otherwise expect - so we don't have the backtraces there. I don't know what the required permissions are to write to the journal stdout/stderr - I think this is an inherited socket fd.
Assigning the bug to myself, because David handed the Flatpak stack to me. It's just book-keeping, I am not actually working on this bug right now.
Zdeněk, do you need some help to move this forward? I think, generally speaking, we should target this for Fedora 37. We have enough time to work out the rough edges in Rawhide.
I can help you with writing a new policy.
(In reply to Zdenek Pytela from comment #7) > I can help you with writing a new policy. Thanks for the offer. That will be wonderful. We already have a SELinux policy module here: https://github.com/flatpak/flatpak/tree/main/selinux Do you want to improve it? Something else? I might be missing some historical context around this bug, and on top of that my knowledge of SELinux is limited.
*** Bug 2072243 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora Linux 37 development cycle. Changing version to 37.