Re: MLS dominance check behavior on el7

From: Chad Hanson <dahchanson@gmail.com>
To: Chris PeBenito <pebenito@ieee.org>
Cc: Stephen Smalley <sds@tycho.nsa.gov>, Joe Nall <joe@nall.com>,
	selinux@vger.kernel.org, SELinux <selinux@tycho.nsa.gov>
Subject: Re: MLS dominance check behavior on el7
Date: Mon, 8 Oct 2018 22:37:18 -0400	[thread overview]
Message-ID: <20181009023718.GD2402@localhost.localdomain> (raw)
In-Reply-To: <308ffdc6-6d82-cdd0-4863-c08432b8b8de@ieee.org>

On Fri, Oct 05, 2018 at 04:05:13PM -0400, Chris PeBenito wrote:
> 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@tycho.nsa.gov> 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.

We are not using this permission anymore, so I concur in removing it as
well.

-Chad