Is unconfined_mount_t allowed to run with system role ?

[GargiQcom]

Hi,

In our setup, we use adb shell to perform certain operations, where the shell runs with developer (root) privileges.

Since meta-selinux does not provide an adb domain, the SELinux policy for adb shell has been added via meta-openembedded. The relevant patch is available here:
https://github.com/openembedded/meta-openembedded/blob/master/meta-oe/dynamic-layers/selinux/recipes-security/refpolicy/refpolicy-targeted/0001-Added-sepolicy-for-adb-service.patch

On the target, the adb shell context is as follows:

adb shell id
uid=0(root) gid=0(root) groups=0(root) context=system_u:system_r:unconfined_t:s0

When running the mount command from this shell, we encounter the following SELinux error:

type=SELINUX_ERR msg=audit(44.591:158): op=security_compute_sid
invalid_context="system_u:system_r:unconfined_mount_t:s0"
scontext=system_u:system_r:unconfined_t:s0
tcontext=system_u:object_r:mount_exec_t:s0
tclass=process

This suggests that unconfined_mount_t is not permitted to run with the system role.

Could you please advise whether it is acceptable to allow unconfined_mount_t to run with the system role as well?
Specifically, is the following change to refpolicy considered acceptable?
https://github.com/openembedded/meta-openembedded/pull/1035/changes

[pebenito]

I would prefer not. In fact, I'd also like to remove unconfined_t and other similar names from system_r.

[pebenito]

To further clarify, system_r:unconfined_t was used early in the "targeted" policy. However, now that init_t and initrc_t are unconfined, a transition to system_r:unconfined_t shouldn't be necessary.

[jaihindy]

Thank you for the clarification.

We understand that system_r:unconfined_t was historically used early in the targeted policy, and that today both init_t and initrc_t are unconfined. From a policy model perspective, the transition may indeed seem unnecessary.

However, in practice, without this change, basic commands such as mount fail when executed from the shell. As per prior guidance from refpolicy maintainers, running adb shell in the unconfined_t domain made sense, since unconfined_t is also suitable for interactive shells. With adb shell running in initrc_t (i.e., without this change), we observe that even common commands like ping do not work as expected.

Given this, our intent with this change is to preserve functional parity for basic shell usage while remaining aligned with the refpolicy model. If this approach is not acceptable, then it likely means the earlier policy change of running adb shell in unconfined_t should also be reverted, as it no longer provides the intended benefits.

Could you please advise on the preferred direction here? We are happy to adjust—either by reworking this change or reverting the earlier adb shell transition—based on what is considered the correct long-term approach in refpolicy.

Thank you for your guidance.

[pebenito]

Ideally, since adb is woking on behalf of a user, it probably makes sense to transition it all the way to unconfined_u:unconfined_r:unconfined_t so the user transitions and experience work as expected.

I'm not familiar with how adbd is architected (as in the design of the daemon itself) but it may be difficult/impossible to make only the shell portion run in this domain. If you have to make the enitire process unconfined, then using SELinuxContext=unconfined_u:unconfined_r:unconfined_t in the systemd unit may work. An alternative is to add a role_transition, though you'd have to add unconfined_r to system_u.

[jaihindy]

Thanks for the clarification and for sharing your perspective.
To add some concrete context from the implementation side: adbd does not directly act as the interactive shell. When an adb shell session is started, adbd explicitly forks a child process and execs the shell binary (/system/bin/sh). This is visible in AOSP’s adb/shell_service.cpp, where the child path ultimately calls execle(_PATH_BSHELL, …) after forkpty() / fork(). Because of this exec boundary, the shell runs as a distinct process and does not require the long‑running daemon itself to be unconfined.
Coming to the specific policy concern we are trying to address:
the practical issue we hit is that mount is not permitted from the adb shell context, and the minimal requirement to fix this is allowing the shell to transition into a domain that can perform mounts. For that, we are proposing:
mount_run_unconfined(unconfined_t, system_r)
So the concrete question from our side is:

Would you be okay approving the above unconfined_mount_t addition, given that it is required specifically for mount and does not unconfine the daemon?
If this is not acceptable from a refpolicy point of view, please let us know, and we can revert the original change that runs the adb shell in an unconfined domain and align with upstream preference.

We want to make sure we follow the refpolicy direction here, so guidance on whether this narrowly scoped change is acceptable would be very helpful.
Thanks again for the review, and please let us know if any additional details are needed.

[pebenito]

We want to make sure we follow the refpolicy direction here, so guidance on whether this narrowly scoped change is acceptable would be very helpful.

The difficulty is that there is no adbd in refpolicy, so I'm reluctant to take changes for something that is unsupported.

Ideally the best change would likely to add code to adbd so it does a setexeccon(unconfined_u:unconfined_r:unconfined_t:s0...) before it does the execle on the shell. I'm guessing that would not be preferred by you, so the second best choice would be to have a type and role transition on shell_exec_t to get unconfined_r:unconfined_t. You'll also need to associate unconfined_r with system_u.