User range vs. context's range

User range vs. context's range

[Christopher J. PeBenito]

What is the intended behavior for a user's allowed range in the policy
vs. any labels in the policy (e.g. netifcon)?  My expectation is that
the allowed range should still apply, but it doesn't seem that
checkpolicy checks that, based on what I've seen.  For example, the new
sediff test policies have this user[1]:

user added_user roles system level s1 range s1;

and checkpolicy doesn't error on this[2] later in the policy:

genfscon added_genfs / added_user:object_r:system:s0

I think this should fail compilation since s0 is not in added_user's
allowed range.



[1]
https://github.com/TresysTechnology/setools/blob/master/tests/diff_right.conf#L605
[2]
https://github.com/TresysTechnology/setools/blob/master/tests/diff_right.conf#L633

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

Re: User range vs. context's range

[Stephen Smalley]

On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
> What is the intended behavior for a user's allowed range in the policy
> vs. any labels in the policy (e.g. netifcon)?  My expectation is that
> the allowed range should still apply, but it doesn't seem that
> checkpolicy checks that, based on what I've seen.  For example, the new
> sediff test policies have this user[1]:
>
> user added_user roles system level s1 range s1;
>
> and checkpolicy doesn't error on this[2] later in the policy:
>
> genfscon added_genfs / added_user:object_r:system:s0
>
> I think this should fail compilation since s0 is not in added_user's
> allowed range.

Not for objects (object_r), same as with role-type relation.

Re: User range vs. context's range

[Christopher J. PeBenito]

On 1/20/2016 4:22 PM, Stephen Smalley wrote:
> On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
>> What is the intended behavior for a user's allowed range in the policy
>> vs. any labels in the policy (e.g. netifcon)?  My expectation is that
>> the allowed range should still apply, but it doesn't seem that
>> checkpolicy checks that, based on what I've seen.  For example, the new
>> sediff test policies have this user[1]:
>>
>> user added_user roles system level s1 range s1;
>>
>> and checkpolicy doesn't error on this[2] later in the policy:
>>
>> genfscon added_genfs / added_user:object_r:system:s0
>>
>> I think this should fail compilation since s0 is not in added_user's
>> allowed range.
> 
> Not for objects (object_r), same as with role-type relation.

I don't understand the logic for that.  For the role-type relation, all
types are implicitly added to object_r, which makes that behavior make
sense, but the user has an explicitly-stated allowed range.

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

Re: User range vs. context's range

[Stephen Smalley]

On 01/21/2016 08:14 AM, Christopher J. PeBenito wrote:
> On 1/20/2016 4:22 PM, Stephen Smalley wrote:
>> On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
>>> What is the intended behavior for a user's allowed range in the policy
>>> vs. any labels in the policy (e.g. netifcon)?  My expectation is that
>>> the allowed range should still apply, but it doesn't seem that
>>> checkpolicy checks that, based on what I've seen.  For example, the new
>>> sediff test policies have this user[1]:
>>>
>>> user added_user roles system level s1 range s1;
>>>
>>> and checkpolicy doesn't error on this[2] later in the policy:
>>>
>>> genfscon added_genfs / added_user:object_r:system:s0
>>>
>>> I think this should fail compilation since s0 is not in added_user's
>>> allowed range.
>>
>> Not for objects (object_r), same as with role-type relation.
>
> I don't understand the logic for that.  For the role-type relation, all
> types are implicitly added to object_r, which makes that behavior make
> sense, but the user has an explicitly-stated allowed range.

If that's true, it is only true of setools, not of libsepol or the 
kernel binary policy.  policydb_context_isvalid() omits the role-type 
and user-role relation checks if the role is object_r, and 
mls_context_isvalid() does likewise for the user-range relation check.

Re: User range vs. context's range

[Stephen Smalley]

On 01/21/2016 04:49 PM, Stephen Smalley wrote:
> On 01/21/2016 08:14 AM, Christopher J. PeBenito wrote:
>> On 1/20/2016 4:22 PM, Stephen Smalley wrote:
>>> On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
>>>> What is the intended behavior for a user's allowed range in the policy
>>>> vs. any labels in the policy (e.g. netifcon)?  My expectation is that
>>>> the allowed range should still apply, but it doesn't seem that
>>>> checkpolicy checks that, based on what I've seen.  For example, the new
>>>> sediff test policies have this user[1]:
>>>>
>>>> user added_user roles system level s1 range s1;
>>>>
>>>> and checkpolicy doesn't error on this[2] later in the policy:
>>>>
>>>> genfscon added_genfs / added_user:object_r:system:s0
>>>>
>>>> I think this should fail compilation since s0 is not in added_user's
>>>> allowed range.
>>>
>>> Not for objects (object_r), same as with role-type relation.
>>
>> I don't understand the logic for that.  For the role-type relation, all
>> types are implicitly added to object_r, which makes that behavior make
>> sense, but the user has an explicitly-stated allowed range.
>
> If that's true, it is only true of setools, not of libsepol or the

By "that", I mean "all types are implicitly added to object_r".  I don't 
see that anywhere in libsepol or the kernel. I do see it in libqpol. 
But if you dump a kernel policy and look at object_r's role->types, they 
are empty.

> kernel binary policy.  policydb_context_isvalid() omits the role-type
> and user-role relation checks if the role is object_r, and
> mls_context_isvalid() does likewise for the user-range relation check.

Re: User range vs. context's range

[Christopher J. PeBenito]

On 1/21/2016 4:49 PM, Stephen Smalley wrote:
> On 01/21/2016 08:14 AM, Christopher J. PeBenito wrote:
>> On 1/20/2016 4:22 PM, Stephen Smalley wrote:
>>> On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
>>>> What is the intended behavior for a user's allowed range in the policy
>>>> vs. any labels in the policy (e.g. netifcon)?  My expectation is that
>>>> the allowed range should still apply, but it doesn't seem that
>>>> checkpolicy checks that, based on what I've seen.  For example, the new
>>>> sediff test policies have this user[1]:
>>>>
>>>> user added_user roles system level s1 range s1;
>>>>
>>>> and checkpolicy doesn't error on this[2] later in the policy:
>>>>
>>>> genfscon added_genfs / added_user:object_r:system:s0
>>>>
>>>> I think this should fail compilation since s0 is not in added_user's
>>>> allowed range.
>>>
>>> Not for objects (object_r), same as with role-type relation.
>>
>> I don't understand the logic for that.  For the role-type relation, all
>> types are implicitly added to object_r, which makes that behavior make
>> sense, but the user has an explicitly-stated allowed range.
> 
> If that's true, it is only true of setools, not of libsepol or the
> kernel binary policy.  policydb_context_isvalid() omits the role-type
> and user-role relation checks if the role is object_r, and
> mls_context_isvalid() does likewise for the user-range relation check.

Apologies for being misled by the long-time setools object_r behavior
(I'll undo that).  However, I still disagree with ignoring the
user-range check in the object_r case, because there is an explicit
user-range relationship written in the policy.


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

Re: User range vs. context's range

[Stephen Smalley]

On 01/22/2016 09:00 AM, Christopher J. PeBenito wrote:
> On 1/21/2016 4:49 PM, Stephen Smalley wrote:
>> On 01/21/2016 08:14 AM, Christopher J. PeBenito wrote:
>>> On 1/20/2016 4:22 PM, Stephen Smalley wrote:
>>>> On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
>>>>> What is the intended behavior for a user's allowed range in the policy
>>>>> vs. any labels in the policy (e.g. netifcon)?  My expectation is that
>>>>> the allowed range should still apply, but it doesn't seem that
>>>>> checkpolicy checks that, based on what I've seen.  For example, the new
>>>>> sediff test policies have this user[1]:
>>>>>
>>>>> user added_user roles system level s1 range s1;
>>>>>
>>>>> and checkpolicy doesn't error on this[2] later in the policy:
>>>>>
>>>>> genfscon added_genfs / added_user:object_r:system:s0
>>>>>
>>>>> I think this should fail compilation since s0 is not in added_user's
>>>>> allowed range.
>>>>
>>>> Not for objects (object_r), same as with role-type relation.
>>>
>>> I don't understand the logic for that.  For the role-type relation, all
>>> types are implicitly added to object_r, which makes that behavior make
>>> sense, but the user has an explicitly-stated allowed range.
>>
>> If that's true, it is only true of setools, not of libsepol or the
>> kernel binary policy.  policydb_context_isvalid() omits the role-type
>> and user-role relation checks if the role is object_r, and
>> mls_context_isvalid() does likewise for the user-range relation check.
>
> Apologies for being misled by the long-time setools object_r behavior
> (I'll undo that).  However, I still disagree with ignoring the
> user-range check in the object_r case, because there is an explicit
> user-range relationship written in the policy.

It was only intended for subjects, not for objects.
Whether or not a subject can create an object at a level outside its own 
range depends on the mls constraints.

Re: User range vs. context's range

[James Carter]

On 01/22/2016 09:07 AM, Stephen Smalley wrote:
> On 01/22/2016 09:00 AM, Christopher J. PeBenito wrote:
>> On 1/21/2016 4:49 PM, Stephen Smalley wrote:
>>> On 01/21/2016 08:14 AM, Christopher J. PeBenito wrote:
>>>> On 1/20/2016 4:22 PM, Stephen Smalley wrote:
>>>>> On 01/20/2016 03:59 PM, Christopher J. PeBenito wrote:
>>>>>> What is the intended behavior for a user's allowed range in the policy
>>>>>> vs. any labels in the policy (e.g. netifcon)?  My expectation is that
>>>>>> the allowed range should still apply, but it doesn't seem that
>>>>>> checkpolicy checks that, based on what I've seen.  For example, the new
>>>>>> sediff test policies have this user[1]:
>>>>>>
>>>>>> user added_user roles system level s1 range s1;
>>>>>>
>>>>>> and checkpolicy doesn't error on this[2] later in the policy:
>>>>>>
>>>>>> genfscon added_genfs / added_user:object_r:system:s0
>>>>>>
>>>>>> I think this should fail compilation since s0 is not in added_user's
>>>>>> allowed range.
>>>>>
>>>>> Not for objects (object_r), same as with role-type relation.
>>>>
>>>> I don't understand the logic for that.  For the role-type relation, all
>>>> types are implicitly added to object_r, which makes that behavior make
>>>> sense, but the user has an explicitly-stated allowed range.
>>>
>>> If that's true, it is only true of setools, not of libsepol or the
>>> kernel binary policy.  policydb_context_isvalid() omits the role-type
>>> and user-role relation checks if the role is object_r, and
>>> mls_context_isvalid() does likewise for the user-range relation check.
>>
>> Apologies for being misled by the long-time setools object_r behavior
>> (I'll undo that).  However, I still disagree with ignoring the
>> user-range check in the object_r case, because there is an explicit
>> user-range relationship written in the policy.
>
> It was only intended for subjects, not for objects.
> Whether or not a subject can create an object at a level outside its own range
> depends on the mls constraints.
>
>

So CIL does not treat object_r as special (except when creating the binary 
policy), so that genfscon statement would cause an error in CIL. Subject and 
object contexts are not treated differently by CIL, but that can be changed if 
needed. I hadn't known that there was a difference.


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency