sway: new policy module

[WavyEbuilder]

Very WIP atm. PR created early such that others can give feedback as it progresses given that Wayland is still very novel in reference policy.

@pebenito Couple questions while I'm working on this:

• I'm considering going the $1_sway_t approach - do you think this is useful? I noticed that we don't rely solely on UBAC for protection (e.g. with $1_systemd_t and hence I think given the scope of the compositor this might be desirable.
• I did consider giving the wayland_compositor typeattribute manage files perms on wayland_compositor_tmpfs_type, but decided against this so that different running compositors can't "contaminate" each others tmpfs's - I don't think this is a huge deal, but it adds a bit of repetition for consumers of the Wayland module (each compositor needs to give itself manage file perms + map on its tmpfs). Would you like me to change this? I personally think having them be separate is the best approach, but of course open to suggestions/ideas.

Anyone else please also free to leave reviews and/or comment, very much open to opinions for this.

cc @aerusso @0xC0ncord

Thanks!

[WavyEbuilder]

w.r.t to needing $1_sway_t, I just realised I don't have a choice anyway, I of course need to domtrans things executed by sway out, and because it prefixes with /bin/sh before executing, that's obviously going to need to be to the respective $user_ts, and there is of course no domtranses to different domains from the same file entrypoint for the same domain. So I guess that settles that.

[WavyEbuilder]

There's a lot of Wayland module related changes now that I'm using it in an actual compositor, so I'll split that out into a separate PR as that can be merged before this (ideally we can get some of the base sway tools in this one too, e.g. swaynag and swaymsg).

[pebenito]

I did consider giving the wayland_compositor typeattribute manage files perms on wayland_compositor_tmpfs_type, but decided against this so that different running compositors can't "contaminate" each others tmpfs's

I'm not familiar with these aspects of wayland, but I suspect they should be separate too.

I don't think this is a huge deal, but it adds a bit of repetition for consumers of the Wayland module (each compositor needs to give itself manage file perms + map on its tmpfs). Would you like me to change this? I personally think having them be separate is the best approach, but of course open to suggestions/ideas.

Perhaps a template would help with the repetition.