Bug 1937404 - Allow nnp_transition for init_t -> install_t
Summary: Allow nnp_transition for init_t -> install_t
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: selinux-policy
Version: 34
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Zdenek Pytela
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 1955547
TreeView+ depends on / blocked
 
Reported: 2021-03-10 15:13 UTC by Colin Walters
Modified: 2021-04-30 11:07 UTC (History)
9 users (show)

Fixed In Version: selinux-policy-3.14.7-28.fc34
Clone Of:
: 1955547 (view as bug list)
Environment:
Last Closed: 2021-03-29 00:17:03 UTC
Type: Bug
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github fedora-selinux selinux-policy pull 642 0 None open install_t: Allow NoNewPriv transition from systemd 2021-03-11 15:58:55 UTC

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.


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