Rethinking interaction with user content.

In the user space there is often a lot of policy to write that defines how users can interact with user content. We usually use the role templates for this. If an confined app create user home, tmp and tmpfs content. We have to allow the user running the app to manage and relabel this content as well.

In Fedora a start was made to simplify this a bit. Users that have access to the userdom_manage_home_role template are able to manage and relabel any content that is declared userdom_user_home_content. This way we do not have to explicitly define that a user can manage/ relabel some confined apps user home content. Less policy to write. Fedora has this idea only implemented for user_home_content and not for user_tmp or tmpfs_content.

The userdom_manage_user_home_role is an old template that dates back to the time when we used roles to separate access to content. Also Fedora combines policy to manage/ relabel and do a bunch of other stuff in this single template. This is not really tidy.

Ive been wanting the idea that Fedora implemented for user home content, for user_tmp and tmpfs content as well. It might save me from writing more policy then strictly required. Hopefully also for pulseaudio which requires processes to manage files on tmpfs. Each application that uses pulseaudio needs to be able to read and delete every other apps pulseaudio tmpfs file, and then send a null signal that the application that owned the tmpfs file it deleted or read. A LOT of policy, which i am hoping to simplify.

There are some things to consider as well. We have different classes of users. We have unconfined users, which obviously should be able to manage all user content. We also have confined common users. These users are restricted but should behave as normal Linux users as much as possible. Thus should also be able to manage and relabel all user content.

Then there are the restricted users. These users have least privileges required. There are two kinds of those. restricted users and restricted xwindows users. An example of an restricted user domain is guest_t, and an example of an restricted xwindows user is xguest_t.

restricted xwindows users need to be able to manage and relabel user content like pulseaudio tmp, tmpfs and user content. And content like Gnome content, Gconf, Window manager, home bin,cert,video, audio etc.

normal restricted users like guest only need to be able to manage generic user content.

Xguest_t also needs some special permission besides the basic restricted xwindows permissions, namely managing and relabelling mozilla_user_content and nsplugin_user_content. and since mozilla_t can transition to for example totem_t, these users should also be able to manage totem user content for example.

So i started by declaring three attributes: user_home_type, user_tmp_type and user_tmpfs_type. These attributes get assigned to all user content. So if an user app manages a file in home, then the type of that content is assigned the user_home_type attribute. If it manages a file on tmpfs it gets assigned the user_tmpfs_type attribute and if it manages a file in tmp the type of that content gets assigned the user_tmp_type attributes. This is done in the userdom_user (home,tmp,tmpfs) content templates which should be used if a type for that purpose is declared.

I have replaced the userdom_manage (home.tmp,tmpfs) role templates by templates that differentiate between generic user content and all user content. If have also separated the manage, relabel and file transition permissions.

The way i plan to use this is as follows: The userdom_login_user_template is shared by all login users (except unconfined users in fedora) So that means both common and restricted users. Therefore, if i add the userdom_manage_all_home_content template call there then that would mean that restricted users can manage all user content. Not what i want. Instead i will add permission to manage relabel and file transition to generic user content to this template. For common users i additionally plan to add permissions to manage and relabel all user content. Unconfined users also get access to manage and relabel all content in the unconfined user module obviously.

Next thing i plan to do is to extend the restricted_xwindows template to permit managing and relabelling of content that is required for GUI interfaces like gnome content etc.

Permissions specific to xguest like managing mozilla user content (xguest is permitted to un firefox in the mozilla_t domain) etcetera will be added to the xguest module.

With this i hope to achieve that i can simplify user content and at the same time keep privileges as tight as possible.

If you want to see what i have implemented of above thus farm have a look in my Git repository. Use Git log/show to find and review the related commits.