Some SELinux experiences that i want to share with you:

Disclaimer: I am just thinking out loud here, and i am sure that in some cases i do not fully understand the complexity or the underlying ideas of, and behind the issues that i am about to describe.

1. (not fedora specific)
User space processes own files on tmpfs for pulseaudio. These user space processes want to read (and unlink) each others pulseaudio files on tmpfs. To facilitate this, it requires much policy and also by allowing a user space process to read another user space processes pulseaudio tmpfs files , you also give it access to the user space process non pulseaudio tmpfs files. which might not be desired.

maybe somehow we can implement a attribute for user space processes pulseaudio files on tmpfs. and/or create a generic interface for this interaction.

3. (fedora specific)
xserver policy has been modified and xserver_user_x_domain_template and xserver_x_domain_template have been added. These templates could be used instead of xserver_user_client and xserver_common_app.

By calling these templates other xserver related policy in the domain that call it can for a large part also be removed. The interfaces mentioned above include most of the required xserver policy for user and application processes to function.

There are some notable exceptions:

xserver_rw_xdm_home_files

Also it appears that the interfaces mentioned above were designed with mls policy in mind. To be able to enable xserver object manager in a way that could benefit targeted policy i think a solution could be found so that xserver policy can be easily extended to provide a basic multi purpose useable policy for targeted as well ( maybe create interfaces for the various scenarios ) so that interfaces (or maybe tunable policy) can be called to make xserver object manager work in a basic form and/or specific form in targeted policy.

So that the admin can easily extend xserver policy for his custom needs without having to write local policy himself or having to implement his own custom interfaces, at least as much as possible.

An example of stuff that currently has no policy implemented but in many cases is required is for example the functionality to change mouse button (for left handed people) and the use of acceleration (3d)

Also we should keep in mind that there is a allow_write_xshm boolean that probably should be used where ever required instead of allowing access to this by adding fixed policy.

My point is that i think xserver object manager could at least to some extend be usable in a targeted policy, and that it could be extendible. Currently in fedora there is no easy way to make openoffice work nice with XACE. I cannot extend its policy due to 'not within scope issues' (user domain prefixes). The java SELinux implementation suffers similar issues.

3. (not fedora specific)
This also brings me to staff and user domains. These domains do not have access to some devices (cannot rw to dri, cannot rw to wifi, webcam etc) maybe we should implement some booleans for this with a $1. e.g. userdom_$1_use_dri etc. or maybe create users domains that add this functionality. I think this is a requirement to makes confined domains acceptable for day-to-day GUI use. Also the allow_execmem boolean is a bit too coarse. Lets face it we are not close to a working none execmem/execstack environment yet. For example nautilus requires it, totem, etc. many of these apps run in the user domain. Setting allow_execmem would in my view be overkill to just allow a single user domain execmem permission. allow_$1_execmem, where $1 is a specific user domain would in my view be a reasonable temporary solution. In either case i do not think we should just ignore the issue.

The "easy" access to execmem and devices like dri are in my view important to help make confined user domains usable for the general public in a GUI environment.