[refpolicy] Policy modules design guidelines?

[sven.vermeulen@siphos.be (Sven Vermeulen)]

On Thu, Jan 13, 2011 at 09:30:19PM +0100, Dominick Grift wrote:
> My opinion on this is different and the mozilla example is a good
> example as to why my opinion is different.
> 
> My opinion is that it is preferred to use the per role template with the
> role prefixes, as this does not hurt and it offers flexibility for cases
> that may not have been foreseen.
> 
> Like mozilla, in refpolicy mozilla is not prefixed. For this reason i
> had to redo mozilla policy in my policy that is built on reference
> policy. I think refpolicy should be as general as possible. With that i
> mean it should be usable whichever way you want to go with you
> customized policy.
> 
> Back to mozilla, i have confined thunderbird as well. As you may know
> thunderbird can run firefox (click a URL in a mail messages) and firefox
> can run thunderbird (send link..)
> 
> So firefox needs to transition to thunderbird and vice versa. But in a
> confined user space you will may want to want different firefox policy
> depending on who runs it. Therefore you need to prefix the firefox and
> thunderbird domains.
> 
> examples:
> 
> user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t
> staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t
> 
> This is why i prefer the prefix domains. It does not hurt to use them
> and who knows, you may need it later (and my experience says that many
> user apps are able to run other agents)
> 
> my two cents

What I'm thinking about was how domains can influence each other. Most
application domains (like mozilla_t) have some permissions for feedback
(such as sigchld/signull sending, fd usage, ...) towards the "caller"
domain. I would expect that this is quite harmless, but I can imagine that
a well-versed malicious person is able to "influence" a more privileged
domain through this.

Let me explain with the following example: a staff_u mapped user runs by
default in the staff_t domain and launches firefox (transitioning to
mozilla_t). He also (in a different terminal) switches role to sysadm_r to
perform some administrative tasks.

Now, permission-wise, the policy allows the same privileges from mozilla_t
to sysadm_t and staff_t. In my imagination, I would see a malicious user
influencing the running firefox through whatever exploit available and
having the permissions to manipulate some aspects within the sysadm_t
domain. Not much and far fetched most likely, but I leave that to the
experts in the field.

  +---------+              +-----------+
  | staff_t |<------------>| mozilla_t |
  +---------+              +-----------+
                                ^
				|
  +----------+                  |
  | sysadm_t |<-----------------/
  +----------+

When using the templates, there would be no SELinux permission whatsoever
from the prefixed mozilla domain to the sysadm_t domain:

  +---------+               +-----------------+
  | staff_t |<------------->| staff_mozilla_t |
  +---------+               +-----------------+

  +----------+                    
  | sysadm_t |
  +----------+

Of course, not allowing sysadm_t to use mozilla will also achieve the same
result, but by using templates it seems like this is a bit more under
control.

The largest impact I see is that this creates most of the rules in the
interfaces, requiring a base rebuild for each update (whereas updates in the
.te file can be done through module updates without affecting base), but I'm
not sure what this "impact" means on manageability and such. At least, I
haven't gotten any issues on this for the time being.

Wkr,
	Sven Vermeulen