On 09/11/2018 12:53 PM, Joshua Brindle wrote:
On Tue, Sep 11, 2018 at 10:41 AM, Stephen Smalley <s...@tycho.nsa.gov> 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).
Isn't the actual question what the GLB of the 2 contexts is, rather
than what permissions one has on the other? It seems like a hack to
use permissions to figure out dominance.
Would a libselinux interface to determine glb and lub of 2 contexts
make sense? Or maybe add a default_range glb and lub option and then
calculate it using relabel?
At least as used in mcstrans, it appears to be a way of matching which
entry from the colors configuration to use. So it is just a "Can
context C1 use the colors specified for context C2?" question. It just
happens that the way they are deciding that for the MLS part is through
the dominance relation. And determining whether context C1 dominates
context C2 is something only the kernel security server or libsepol with
the same policy file loaded into it can answer, not libselinux or
anything else.
_______________________________________________
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.
