[refpolicy] Policy modules design guidelines?

[cpebenito@tresys.com (Christopher J. PeBenito)]

On 1/15/2011 4:03 PM, Sven Vermeulen wrote:
> 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 |
>    +---------+               +-----------------+

This is how it used to be; the role was encoded in the types.  It was 
decided that this slim reduction of flexibility was worth the huge 
reduction of complexity in the policy.

Originally we wanted to use the existing SELinux RBAC functionality to 
keep a true role-based separation.  However, that required kernel 
modifications since labeling objects with a role other than object_r 
doesn't work completely right (e.g. creating files).  We decided to go 
with UBAC since in systems that actually use multiple roles seriously, 
and really care about this, already have a 1:1 user:role mapping.

I would still like to get the true RBAC separation done, but someone 
needs to find some time to fix the kernel.

You can look in the archives back in 2008 to see more discussion about 
all of this.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com