Proposal: add an attribute for application execute and transition permissions

[0xC0ncord]

With the introduction of systemd user support, access needs to be added to $1_systemd_t for various applications if we want these to be run and transitioned properly. Other applications normally run by users such as window managers may also require such access. Instead of adding calls to myapp_run() for each of these applications, I think an attribute for this kind of access may be more suitable.

Such an attribute, staff_app_runner_domain for example, would have all the necessary access granted by interface calls like chromium_run(), and all that would be needed to ensure some domain has the same access to run applications would be to associate the staff_app_runner_domain to it, such as staff_systemd_t. That way, any application that can normally be run by staff_t can also be run by staff_systemd_t. Of course, explicitly allowing access to staff_t or staff_systemd_t can be used where appropriate.

I feel that this also has the advantage of making local policy development significantly easier to do, as one would not need to call the appropriate interfaces for every application that staff_t can normally run to whatever local policy module is being written. On the contrary, as pointed out in earlier discussion, this may overcomplicate refpolicy somewhat.

[pebenito]

I agree that something is needed to solve this issue, and I think the Fedora policy has this type of attribute for a long time, but I've resisted it for a long time. I think this is finally a reason to do it.

[0xC0ncord]

Looking at Fedora's policy, they create a $1_usertype attribute in userdom_base_user_template() that gets the same access that $1_t in refpolicy would. However, I only see that attribute being associated with $1_t and $1_wine_t or similar. I think that for what I would like to accomplish, that's a lot more permissive than I would like, and I think that an app's access to things like the user's home content should continue to be conditional. I think for starters, we can give access for executing other applications as well as allow $1_t and $1_systemd_t to have signal_perms on these application domains and work from there.

[0xC0ncord]

I am anticipating getting to this soon, but I already worry that this might end up in needing to change the signatures of the interfaces for things like chromium_role() to include the prefix, which would then turn them into templates instead, or other such weirdness.

[github-actions]

This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress.

[0xC0ncord]

Was kinda hoping that linking this issue in the PR would not cause the bot to get upset, so here's an explicit activity bump.

[github-actions]

This issue has not had any recent activity. It will be closed in 7 days if it makes no further progress.

[0xC0ncord]

Not stale, waiting review on #412