Re: User range vs. context's range

["Christopher J. PeBenito" <cpebenito@tresys.com>]

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