On 09/11/2018 03:04 PM, Joe Nall wrote:
On Sep 11, 2018, at 1:29 PM, Stephen Smalley <s...@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.
_______________________________________________
Selinux mailing list
Selinux@tycho.nsa.gov
To unsubscribe, send email to selinux-le...@tycho.nsa.gov.
To get help, send an email containing "help" to selinux-requ...@tycho.nsa.gov.