[refpolicy] Policy modules design guidelines?

[domg472@gmail.com (Dominick Grift)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/17/2011 03:44 PM, Christopher J. PeBenito wrote:
> 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.

As i recall it this was more aimed towards derived object types, and not
so much derived domain types.

I remember dwalsh had issue with prefixed object types because it was
not scalable. where on one system you are staff_t and another user_t
(mounted home directories/nis etc)

I do not see how that applies to domain types.

I do agree that derived domain types add flexibility/complexity but i do
not see how rbac can replace some of the functionality that prefixed
domains and type enforcement provides (e.g. enforce policy for a
application based on who runs the application (role prefix)

Any gui user application should be prefixed in my view because they can
all be run from nautilus and or gpanel (launchers). And if you confine
either gpanel or nautilus there is no way to tell selinux who runs the
application (other then nautilus or gpanel), and we cannot make any
distinction.

On top of that the prefixed type gives me the flexibility to create
prefixed booleans. It allows me to customize a userdomain by just
toggling a few booleans.

currently for me role prefixes for domain types proves to be invaluable
in my pursuit to confine the user space.

> 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.
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk00WywACgkQMlxVo39jgT+B5gCgwg6P/ddkrgG7MeLbmX77N0uI
QVIAoKTgvMgRY3xNiVsdgdpvP5EaoNTz
=XxGU
-----END PGP SIGNATURE-----