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@xxxxxxxxxxxxx> 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
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
