From: cpebenito@tresys.com (Christopher J. PeBenito)
Date: Mon, 17 Jan 2011 15:28:14 -0500
Subject: [refpolicy] Policy modules design guidelines?
In-Reply-To: <4D349AF6.5050508@gmail.com>
References: <20110112204642.GA9459@siphos.be>	<4D2F57EA.4060203@tresys.com>	<4D2F60DB.4020506@gmail.com>	<20110115210302.GA16861@siphos.be>	<4D3455DA.4060608@tresys.com>	<4D345B2C.10302@gmail.com>
	<4D3495B0.8070109@tresys.com> <4D349AF6.5050508@gmail.com>
Message-ID: <4D34A65E.6010607@tresys.com>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 1/17/2011 2:39 PM, Dominick Grift wrote:
> On 01/17/2011 08:17 PM, Christopher J. PeBenito wrote:
>> On 1/17/2011 10:07 AM, Dominick Grift wrote:
>>> 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)
>>
>> Of course it can't replace all possible uses, but it does replace all
>> upstream instances, save the ones where there are execution path issues
>> like su, sudo, and screen.
>>
>> For example, the mozilla policy was exactly the same for all roles,
>> except each only accessed the role-specific home dir, X window, etc.  If
>> all objects in the system have an appropriate role in their context,
>> each instance of mozilla can be cleanly separated by role.
>
> think of all the nice use cases you can have with prefixed domains
> like secmark and many other use cases.
>
> staff_mozilla_t can use firefox to send recv external packets
> user_mozilla_t can use firefox to only send recv internal packets.
>
> staff_mozilla_t can run plugins
> user_mozilla_t cannot run plugins
>
> etc etc.
>
> remember the mozilla_$1... boolean we had?

As I have said before, it was a trade off.  It was discussed and what we 
have is the result of the decision.  I'm sorry it does not match your 
goals perfectly.

>>> 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.
>>
>> Of course people can still do this for their custom policies.  However,
>> upstream is pragmatic with its usage.  The actual security gains by the
>> complexity you suggest tends to be dubious.  As long as that is the
>> case, we'll chose simpler policy.
>>
>
> In my view, upstream should in this case probably ignore/exclude user
> applications all together, no offence. Either she facilitates user space
> confinement or she does not, no dead ends or false hope for integrity on
> the desktop.

That is a black-or-white logical fallacy.  Upstream IS facilitating 
confinement.

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