Bug 2110012

Summary: Support all init_t <=> install_t operations that also work with init_t <=> unconfined_t
Product: [Fedora] Fedora Reporter: Colin Walters <walters>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: low    
Version: 36CC: dwalsh, grepl.miroslav, lvrabec, mmalik, omosnace, pkoncity, vmojzis, zpytela
Target Milestone: ---Keywords: Triaged
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 2111206 (view as bug list) Environment:
Last Closed: 2022-09-12 13:14:35 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 2111206    

Description Colin Walters 2022-07-22 18:03:43 UTC 
I'm trying to reopen and re-land this change: https://github.com/coreos/rpm-ostree/pull/2932
which causes rpm-ostreed to be directly systemd socket activated, which will allow us to drop a  big pile of workarounds for previous bugs in the DBus design.

However, this is denied by policy:

Jul 22 17:54:36 cosa-devsh audit[1]: AVC avc:  denied  { create } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:install_t:s0 tclass=unix_stream_socket permissive=1
Jul 22 17:54:36 cosa-devsh audit[1]: AVC avc:  denied  { setopt } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:install_t:s0 tclass=unix_stream_socket permissive=1
Jul 22 17:54:36 cosa-devsh audit[1]: AVC avc:  denied  { bind } for  pid=1 comm="systemd" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:install_t:s0 tclass=unix_stream_socket permissive=1
Jul 22 17:54:36 cosa-devsh audit[1]: AVC avc:  denied  { listen } for  pid=1 comm="systemd" path="/run/rpm-ostree/client.sock" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:install_t:s0 tclass=unix_stream_socket permissive=1

I keep running into small things like this; please make install_t a strict superset of unconfined_t (i.e. it should just be unconfined_t + mac_admin).
Comment 1 Colin Walters 2022-07-22 20:38:04 UTC 
Alternatively, perhaps what I may try to do in the future is have rpm-ostree fork a child process copy of itself that is wrapped with e.g. `runcon -t install_t` or so, but that would require changing the policy to drop the install_exec_t for /usr/bin/rpm-ostree which would break older versions, unless we can figure out a way to do this compatibly.
Comment 2 Zdenek Pytela 2022-07-25 13:47:03 UTC 
Should work in rawhide already:
rawhide# sesearch -A -s init_t -t install_t -c unix_stream_socket -p bind,create,listen,setopt
allow init_t install_t:unix_stream_socket { accept append bind connect connectto create getattr getopt ioctl listen lock read setattr setopt shutdown write };
rawhide# rpm -q selinux-policy
selinux-policy-37.7-1.fc37.noarch

Also note install_t is an unconfined domain, most of possible permissions are already allowed, IPC are one of the exceptions.
Comment 3 Colin Walters 2022-07-25 15:32:46 UTC 
Thanks!  I'd be nice to ship this in RHEL 9.1 if at all possible; anything I can do to help with that?
I think potentially we can avoid depending on this in F36 lifetime.
Comment 4 Zdenek Pytela 2022-07-26 16:43:29 UTC 
(In reply to Colin Walters from comment #3)
> Thanks!  I'd be nice to ship this in RHEL 9.1 if at all possible; anything I
> can do to help with that?
> I think potentially we can avoid depending on this in F36 lifetime.

Please clone the bz for RHEL 9 then, but note it is quite late in the development cycle.
Comment 5 Zdenek Pytela 2022-08-09 16:06:17 UTC 
(In reply to Colin Walters from comment #3)
> Thanks!  I'd be nice to ship this in RHEL 9.1 if at all possible; anything I
> can do to help with that?
> I think potentially we can avoid depending on this in F36 lifetime.

I don't quite understand. There is a solution in F37, should it be backported to F36, too?
Comment 6 Zdenek Pytela 2022-09-12 13:14:35 UTC 
Just checked the commit has been backported.
Comment 7 Colin Walters 2022-09-12 13:32:19 UTC 
Ah, thanks for backporting.  I had meant to say I think it *didn't* need to be backported, but doing so will definitely make our lives easier in the future.

Thanks again!