Hookup attribute for user applications to run other applications

[0xC0ncord]

This is the second part of the effort previously started in #381.

This PR modifies the calls to every _role() and _role_template() to use the new $1_application_exec_domain where appropriate, while still standardizing these role calls to use this format: myapp_role[_template](user, user_t, user_application_exec_domain, user_r). This PR does not touch any role interfaces that do not have any callers.

$1_application_exec_domain only gets permissions needed to execute and transition to other applications, as well as using stream_connect() on them if it was previously given to userdomains. $1_application_exec_domain does not get access to read or modify application data explicitly.

Additionally, $1_systemd_t gets the permissions needed to monitor applications started by users in order to capture output to journald, check their state, and so on.

Lastly, sudo, su, and shutdown get a new tunable (default off) to control whether $1_application_exec_domain should have access to execute these administrative applications.

Fixes #365

[pebenito]

From the source diff it seems ok, but I noticed something concerning from sediff:

$ sediff policy.33{.orig,} | grep xguest | wc -l
175

These are all additions.

[0xC0ncord]

From the source diff it seems ok, but I noticed something concerning from sediff:

$ sediff policy.33{.orig,} | grep xguest | wc -l
175

These are all additions.

It seems that most of these new rules are to xguest_wm_t, and most of those are allowing xguest_wm_t to transition to various httpd user scripts. Everything else looks fine to me.

I'm not sure what the use case is for xguest having the ability to run httpd user scripts. If you think we should lock this down, I can add a template for httpd user script guest access, or we can remove this call altogether: https://github.com/SELinuxProject/refpolicy/blob/master/policy/modules/roles/xguest.te#L89

[pebenito]

Let's remove the access. I don't see a need for a guest to have apache access. If there is a good reason found in the future, we can reconsider.

[0xC0ncord]

OK. I added another commit to remove apache access from xguest. I also went ahead and did the same thing for normal guest for the same reason.