The advantages and disadvantages of domain prefixes.

I am trying to merge restricted xwindows users and common users. The idea is to make them both use the same policy and be able to lock down what we know as user_t to a restricted user that we know as xguest by toggling booleans. That will make it easier to adept user environments to meet your requirement. You do not have to write custom policy. Simply enable/disable the functionality that you need with booleans and go.

To achieve this i use the good old per_role_templates. We used to use them for role based separation, But once user based separation was introduced there seemed to be not much use to these templates any more. However the domain prefixes used in the per role templates can play an important role in enabling and disabling functionality for different users using the same policy. We can use the domain prefix to define tunable policy.

user joe is allowed to access the network via his web browser. User jane can only access the network with her favourite game. Both use the same policy but have different booleans toggled.

But consider this: joe is allowed to use the browser. The browser can use stuff like java, flash, a video player, email client etc. Its not joe directly run those its the browser running it for joe. So how is it achieved that when it is allowed that joe can use the web browser, that joe can also watch a video clip via his web browser. Or that joe is not allowed to watch video via his browser but some other user is permitted that.

This, i believe can be achieved by called per_role_templates in per_role_templates.

I tried this before in more than one ways and always stumbled on duplicate declarations or out of scope issues. Today i tried a different approach. To avoid duplicate declarations i decided to try and split the per_role_templates into templates for policy and for declarations. The declaration per role templates should only be called by user domains. Whilst the policy per role templates can additionally be called by other policy per role templates. This way booleans, types and attributes are declared once but can be used more than once. For example user X can connect to a streaming port if he runs totem, but he can also connect to a streaming port if he runs totem via his browser. The same can be done for things like java, gpg, flash, web browsers, you name it

Another thing i have to deal with is xserver duplicated declarations, and so i also split those declarations for the policy and added the declaration interface to the per role declaration template for the various applications and the policy to the per role policy template.

This stuff becomes important if you truly want to confine the user space. Take for example nautilus. If you click on a video file in nautilus. How does the SELinux know who did it and thus who's policy to apply? All it knows is that nautilus ran the video file and nautilus is not a user its an application. There are may more such examples. Domain prefixes can help here.

There are also issues with calling per role templates from per role templates. Consider this. You can click on a web url in an E-mail message and you can also use the E-mail client from the web browser. So you called the E-mail per role template from the browser per role template, and you call the browser per role template from the E-mail per role template. This will get you into a loop that never ends. You can wait until you way less than a ounce and policy will still not finish compiling. So that is a issue to consider.

Just to show you what a per role declaration template for a GUI app would look like:

########################################
##

## Role access for mozilla declarations.
##

##
##

## Prefix to be used
##

##
##
##

## Role allowed access
##

##
#
interface(`mozilla_declarations_role',`
gen_require(`
attribute mozilla_domain;
type mozilla_exec_t;
')

##
##

## Allow Mozilla to execute anonymous memory (execmem))
## files.
##

##
gen_tunable(mozilla_$1_execmem, false)

##
##

## Allow Mozilla to read all user home.
## files.
##

##
gen_tunable(mozilla_$1_read_content, false)

##
##

## Network access for mozilla.
## files.
##

##
gen_tunable(mozilla_$1_network_connect, false)

type $1_mozilla_t, mozilla_domain;
application_domain($1_mozilla_t, mozilla_exec_t)
ubac_constrained($1_mozilla_t)

role $2 types $1_mozilla_t;

xserver_object_types_template($1_mozilla)
')

I am aware that this is a pretty dirty hack, and i am not even sure if this indeed works out the way it appears, but i am just glad and hopeful that it does.