role dominance

role dominance

[Joshua Brindle]

While working on policyrep we've found that role dominance is pretty 
difficult to implement correctly, and apparently there is some ambiguity 
about how it works. The main problem we are running into now is that 
converting the role bitmaps of an old module (compatibility) back to a 
role dominance statement is very difficult.

Also it seems like noone has really used role dominance. During 
conversations about it here Chris PeBenito suggests that he wants 
something like it for refpolicy but a role attribute kind of system may 
be much simpler and easier to implement/understand.

Thoughts?


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: role dominance

[Stephen Smalley]

On Mon, 2008-01-07 at 10:41 -0500, Joshua Brindle wrote:
> While working on policyrep we've found that role dominance is pretty 
> difficult to implement correctly, and apparently there is some ambiguity 
> about how it works. The main problem we are running into now is that 
> converting the role bitmaps of an old module (compatibility) back to a 
> role dominance statement is very difficult.

And likely unnecessary.  It isn't required that a conversion yield the
same source representation, but only that it yield the same end result
when you ultimately generate a kernel binary policy.  Or are you saying
that you can't even do the latter?

> Also it seems like noone has really used role dominance. During 
> conversations about it here Chris PeBenito suggests that he wants 
> something like it for refpolicy but a role attribute kind of system may 
> be much simpler and easier to implement/understand.
> 
> Thoughts?

Any language feature that isn't actually being used should probably be
deprecated.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: role dominance

[Christopher J. PeBenito]

On Mon, 2008-01-07 at 12:53 -0500, Stephen Smalley wrote:
> On Mon, 2008-01-07 at 10:41 -0500, Joshua Brindle wrote:
> > While working on policyrep we've found that role dominance is pretty 
> > difficult to implement correctly, and apparently there is some ambiguity 
> > about how it works. The main problem we are running into now is that 
> > converting the role bitmaps of an old module (compatibility) back to a 
> > role dominance statement is very difficult.
> 
> And likely unnecessary.  It isn't required that a conversion yield the
> same source representation, but only that it yield the same end result
> when you ultimately generate a kernel binary policy.  Or are you saying
> that you can't even do the latter?
> 
> > Also it seems like noone has really used role dominance. During 
> > conversations about it here Chris PeBenito suggests that he wants 
> > something like it for refpolicy but a role attribute kind of system may 
> > be much simpler and easier to implement/understand.
> 
> Any language feature that isn't actually being used should probably be
> deprecated.

Last time I tried to use it, the module compiler segfaulted I think.  At
a minimum, I believe it still had ordering issues, making it unusable.
It might see more use if the upcoming experiments on using RBAC for role
separation, rather than derived types, succeeds.  And if it does, the
role attribute might also be useful.

-- 
Chris PeBenito
Tresys Technology, LLC
(410) 290-1411 x150



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: role dominance

[Joshua Brindle]

Stephen Smalley wrote:
> On Mon, 2008-01-07 at 10:41 -0500, Joshua Brindle wrote:
>   
>> While working on policyrep we've found that role dominance is pretty 
>> difficult to implement correctly, and apparently there is some ambiguity 
>> about how it works. The main problem we are running into now is that 
>> converting the role bitmaps of an old module (compatibility) back to a 
>> role dominance statement is very difficult.
>>     
>
> And likely unnecessary.  It isn't required that a conversion yield the
> same source representation, but only that it yield the same end result
> when you ultimately generate a kernel binary policy.  Or are you saying
> that you can't even do the latter?
>
>   

The latter is possible.

>> Also it seems like noone has really used role dominance. During 
>> conversations about it here Chris PeBenito suggests that he wants 
>> something like it for refpolicy but a role attribute kind of system may 
>> be much simpler and easier to implement/understand.
>>
>> Thoughts?
>>     
>
> Any language feature that isn't actually being used should probably be
> deprecated.
>   

I vote for deprecation in the current compiler and no implementation in 
policyrep. If we want to add role attribute that would be fine too. 
Chris wants some way to group roles and I never really thought role 
dominance was the right way to do it.


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: role dominance

[Joshua Brindle]

Joshua Brindle wrote:
> Stephen Smalley wrote:
>> On Mon, 2008-01-07 at 10:41 -0500, Joshua Brindle wrote:
>>  
>>> While working on policyrep we've found that role dominance is pretty 
>>> difficult to implement correctly, and apparently there is some 
>>> ambiguity about how it works. The main problem we are running into 
>>> now is that converting the role bitmaps of an old module 
>>> (compatibility) back to a role dominance statement is very difficult.
>>>     
>>
>> And likely unnecessary.  It isn't required that a conversion yield the
>> same source representation, but only that it yield the same end result
>> when you ultimately generate a kernel binary policy.  Or are you saying
>> that you can't even do the latter?
>>
>>   
>
> The latter is possible.
>
>>> Also it seems like noone has really used role dominance. During 
>>> conversations about it here Chris PeBenito suggests that he wants 
>>> something like it for refpolicy but a role attribute kind of system 
>>> may be much simpler and easier to implement/understand.
>>>
>>> Thoughts?
>>>     
>>
>> Any language feature that isn't actually being used should probably be
>> deprecated.
>>   
>
> I vote for deprecation in the current compiler and no implementation 
> in policyrep. If we want to add role attribute that would be fine too. 
> Chris wants some way to group roles and I never really thought role 
> dominance was the right way to do it.
>

Patch below to deprecate role dominance. I think we should throw a 
warning in policyrep if we see anything in the dominates field of the 
role datum and continue without support. Chris suggests that he'd like 
role attributes so we can put that on the todo list to implement.

Index: checkpolicy/policy_parse.y
===================================================================
--- checkpolicy/policy_parse.y  (revision 2725)
+++ checkpolicy/policy_parse.y  (working copy)
@@ -2563,6 +2563,8 @@
                return (role_datum_t *) 1;      /* any non-NULL value */
        }
 
+       yywarn("Role dominance has been deprecated");
+
        role_id = queue_remove(id_queue);
        if (!is_id_in_scope(SYM_ROLES, role_id)) {
                yyerror2("role %s is not within scope", role_id);



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: role dominance

[Stephen D. Smalley]

> role dominance seems not to be used in the current example policy.  I
> had the impression that you were planning to deprecate it or remove
> it.   Is that wrong?  

We don't use role dominance in the example policy, but the example
policy only defines a few roles and those roles are relatively orthogonal.
If people start defining more complex sets of roles, then they may wish
to define role dominance hierarchies.  For analysis purposes, you can
just expand the role dominance relation into the user-role and role-domain
relations.

The present RBAC language and logic is very simple; I would expect that
people might want to eventually expand it to directly represent more
complex relationships among roles, drawing from prior work that has
been done on RBAC models.  Our own focus has been more on the TE component.

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: role dominance

[Stephen D. Smalley]

> As explained in SELinux documentation, a role automatically inherits the 
> domains authorized for any role that it dominates in the hierarchy. What 
> I don't know is about user-roles associations. Consider the following 
> situation:
> 
> U1: SELinux user identity
> R1, R2: roles
> T1, T2: types
> 
> R1 dominates R2
> R1 is authorized for type T1 and R2 for type T2
> 
> it follows R1 is authorized for type T2 too.
> 
> If U1 is authorized for role R1, certainly (U1, R1, T2) is a valid 
> security context, because of the dominance relation between R1 and R2. 
> What about (U1,R2,T2)? In other words, if a role dominates another role 
> and a user is explicitly authorized to the dominant role, is then the 
> user implicitly authorized to the dominated role?

Yes, the user is implicitly authorized for the dominated role, and (U1,R2,T2) 
would be a valid security context.  

--
Stephen Smalley, NSA
sds@epoch.ncsc.mil


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: role dominance

[Joshua D. Guttman]

"Stephen D. Smalley" <sds@epoch.ncsc.mil> writes:

>   
>   Yes, the user is implicitly authorized for the dominated role, and (U1,R2,T2) 
>   would be a valid security context.  
>   

role dominance seems not to be used in the current example policy.  I
had the impression that you were planning to deprecate it or remove
it.   Is that wrong?  

Thanks --

        Joshua 
-- 
	Joshua D. Guttman		<guttman@mitre.org> 
	MITRE, Mail Stop S119		Office:	+1 781 271 2654
	202 Burlington Rd.		Cell:	+1 781 526 5713
	Bedford, MA 01730-1420 USA	Fax:	+1 781 271 8953



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.