On 10/04/2018 05:01 PM, Stephen Smalley wrote:
On 09/30/2018 10:43 AM, Chris PeBenito wrote:
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>
On 09/11/2018 10:41 AM, Stephen Smalley wrote:
On 09/10/2018 06:30 PM, Ted Toth wrote:
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?
Correct. Only caveat is that removing translate will change the
permission index of contains, which could break a running mcstransd upon
a policy reload (doesn't use selinux_check_access or even the avc; won't
flush the class/perm string mapping on a reload automatically).
Good point. I think I'll remove all the rules and constraints and then
rename the permission to unused or unused_perm. Then the indices will
be stable, but it will be clear the perm is unused.
--
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.
