Bug 1937404

Summary: Allow nnp_transition for init_t -> install_t
Product: [Fedora] Fedora Reporter: Colin Walters <walters>
Component: selinux-policyAssignee: Zdenek Pytela <zpytela>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 34CC: dwalsh, grepl.miroslav, lvrabec, mmalik, omosnace, plautrba, travier, vmojzis, zpytela
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: selinux-policy-3.14.7-28.fc34 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
: 1955547 (view as bug list) Environment:
Last Closed: 2021-03-29 00:17:03 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: 1955547    

Description Colin Walters 2021-03-10 15:13:40 UTC
In rpm-ostree we're trying to do more privilege separation; we added a new systemd unit rpm-ostree-countme.service that uses `DynamicUser=yes`.

However, it turns out that this breaks because we added a special `install_t` label:

```
-rwxr-xr-x. 3 root root system_u:object_r:install_exec_t:s0 127267552 Jan  1  1970 /usr/bin/rpm-ostree
```

Now, this works fine for a regular (privileged) domain transition for our service that starts as root.

But when trying with `DynamicUser=yes` but executing the same binary:

```
Mar 10 14:11:34 cosa-devsh audit[1276]: AVC avc:  denied  { nnp_transition } for  pid=1276 comm="(m-ostree)" scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:install_t:s0 tclass=process2 permissive=0
```

This then leaves the process running as `init_t`, which means we get denied trying to do HTTP:

```
Mar 10 14:11:34 cosa-devsh audit[1276]: AVC avc:  denied  { name_connect } for  pid=1276 comm="rpm-ostree" dest=443 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:http_port_t:s0 tclass=tcp_socket permissive=0
```

I think the immediate fix is to allow the nnp_transition so that this unprivileged process runs as `install_t`, the same as the main one.

But it'd be even better to not do any transition at all, i.e. in the `DynamicUser=yes` case we stay in `unconfined_service_t` to start (the systemd default).  I'm not quite sure how to do that without basically hacking up systemd to do a `setexeccon()` (something declarative like `SELinuxTransition=no` in a systemd unit file?)

Comment 1 Colin Walters 2021-03-10 15:15:30 UTC
In the short term, we are probably going to work around this by shipping two binaries, like `/usr/bin/rpm-ostree` and `/usr/libexec/rpmostree-unprivileged-backend` or something, then the systemd unit execs the latter.

But having two labels means duplicating the binary on disk which is quite unfortunate.  (OSTree could use reflinks for this, but we can't hard require reflinks)

Comment 2 Timothée Ravier 2021-03-11 15:14:49 UTC
We can set SELinuxContext=system_u:system_r:unconfined_service_t:s0 in the systemd unit but this gives us:

```
Mar 11 11:40:03 cosa-devsh audit[3454]: AVC avc:  denied  { entrypoint } for  pid=3454 comm="(m-ostree)" path="/usr/bin/rpm-ostree" dev="vda4" ino=2838494 scontext=system_u:system_r:unconfined_service_t:s0 tcontext=system_u:object_r:install_exec_t:s0 tclass=file permissive=0
```

And I don't think we want to enable that.

Adding nnp_transition to scontext=system_u:system_r:init_t:s0 tcontext=system_u:system_r:install_t:s0 sounds OK from a security perspective (I do not see how this could be exploited) so I will make a PR for that.

Comment 3 Zdenek Pytela 2021-03-16 15:39:33 UTC
commit 3d3b616790d5826f73b259fc2a940a8e1efe98c1 (HEAD -> rawhide, upstream/rawhide)
Author: Timothée Ravier <travier>
Date:   Thu Mar 11 16:53:29 2021 +0100

    install_t: Allow NoNewPriv transition from systemd

    Enable a subset of rpm-ostree commands to run as part of a systemd
    service directly under an unprivilged user with DynamicUser.

    This will be used for the rpm-ostree-countme service.

    Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1937404

Comment 4 Fedora Update System 2021-03-21 16:15:45 UTC
FEDORA-2021-9e2cb00123 has been submitted as an update to Fedora 34. https://bodhi.fedoraproject.org/updates/FEDORA-2021-9e2cb00123

Comment 5 Fedora Update System 2021-03-22 01:17:29 UTC
FEDORA-2021-9e2cb00123 has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-9e2cb00123`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-9e2cb00123

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

Comment 6 Fedora Update System 2021-03-25 01:24:31 UTC
FEDORA-2021-68c09eb43f has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-68c09eb43f`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-68c09eb43f

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

Comment 7 Fedora Update System 2021-03-27 02:01:12 UTC
FEDORA-2021-15b81d905c has been pushed to the Fedora 34 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2021-15b81d905c`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2021-15b81d905c

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

Comment 8 Fedora Update System 2021-03-29 00:17:03 UTC
FEDORA-2021-15b81d905c has been pushed to the Fedora 34 stable repository.
If problem still persists, please make note of it in this bug report.