Re: MLS dominance check behavior on el7

[Chris PeBenito <pebenito@ieee.org>]

On 09/11/2018 04:20 PM, Stephen Smalley wrote:
> On 09/11/2018 03:04 PM, Joe Nall wrote:
>>
>>
>>> On Sep 11, 2018, at 1:29 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>>
>>> On 09/11/2018 10:41 AM, Stephen Smalley wrote:
>>>> On 09/10/2018 06:30 PM, Ted Toth wrote:
>>>>> mcstrans mcscolor.c also uses the same logic I'd been using to 
>>>>> check dominance so this too will no longer function as expected on 
>>>>> el7. Do you any suggestions for doing a 'generic' (one not tied to 
>>>>> a specific resource class) dominance check in lieu of context 
>>>>> contains?
>>>> You should probably define your own permission with its own 
>>>> constraint to avoid depending on the base policy's particular 
>>>> constraint definitions.  Certainly for your own code.  For mcstrans, 
>>>> mcscolor probably ought to be switched to using at least a separate 
>>>> permission in the context class if not its own class to avoid 
>>>> overloading the meaning with pam_selinux's usage (or vice versa, but 
>>>> likely harder to change pam_selinux at this point).
>>>> It is possible to define an entirely new class, its permissions, and 
>>>> its mls constraints via a CIL module IIUC, without needing to change 
>>>> the base policy.
>>>> I don't think you can add a permission to an existing class via a 
>>>> CIL module currently, unfortunately, so you can't just extend the 
>>>> context class without modifying the base policy.  So it may be 
>>>> easier to define an entirely new class.
>>>> The class and permission ought to be specific to the usage.  For 
>>>> example, mcstrans could have its own class (mcstrans) with its own 
>>>> permissions (e.g. color_match or color_use or ...) that abstract 
>>>> away the logical check being performed.  Dominance checks performed 
>>>> for different reasons ought to use different permissions so that one 
>>>> can distinguish what TE pairs are allowed them.
>>>> Your code could likewise define and use its own class and permission.
>>>> Does that make sense?
>>>
>>> BTW, I noticed there is another permission ("translate") defined in 
>>> the context class and its constraint is ((h1 dom h2) or (t1 == 
>>> mlstranslate)).  I would have guessed that it was intended as a 
>>> front-end service check over what processes could request context 
>>> translations from mcstrans or what contexts they could translate, but 
>>> I don't see it being used in mcstrans anywhere.  Is this a legacy 
>>> thing from early setransd/mcstransd days?  There is a TODO comment in 
>>> mcstrans process_request() that suggests there was an intent to 
>>> perform a dominance check between the requester context and the 
>>> specified context, but that's not implemented.  Appears to be allowed 
>>> in current policy for all domains to the setrans_t domain itself.
>>
>> I think 'translate' predates my mcstransd work and dates from the 
>> original TCS implementation. There is an argument to implement that 
>> constraint, but we've been operating without it for so long it does 
>> not seem worthwhile.
> 
> Well, I guess we ought to either implement it or delete the permission 
> definition from refpolicy.

I'm fine removing it.  It's just the translate permission that is 
unused, not the whole class, correct?

-- 
Chris PeBenito