Re: MLS dominance check behavior on el7
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
> > 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
___
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.
Re: [PATCH] libsemanage: improve semanage_migrate_store import failure
Weird Gmail removed my text box for plain text mode in Gmail,
re-sending since it got
filtered out of the mailing list.
On Mon, Oct 8, 2018 at 9:09 AM William Roberts wrote:
>
> Yuli,
> If you respin this with just import error looks like its a go.
> Bill
>
> On Fri, Oct 5, 2018 at 12:53 PM Chris PeBenito wrote:
>>
>> On 10/05/2018 10:32 AM, Jason Zaman wrote:
>> > On Fri, Oct 05, 2018 at 07:13:23AM -0700, William Roberts wrote:
>> >> On Thu, Oct 4, 2018 at 12:46 PM Yuli Khodorkovskiy <
>> >> yuli.khodorkovs...@crunchydata.com> wrote:
>> >>
>> >>> The python module import error in semanage_migrate_store was misleading.
>> >>> Before, it would print that the module is not installed, even though
>> >>> it is in fact on the system.
>> >>>
>> >>> Now the python module import failure is correctly reported if the module
>> >>> is not installed or the exact reason for failure is reported to the user.
>> >>>
>> >>> Signed-off-by: Yuli Khodorkovskiy
>> >>> ---
>> >>> libsemanage/utils/semanage_migrate_store | 6 --
>> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
>> >>>
>> >>> diff --git a/libsemanage/utils/semanage_migrate_store
>> >>> b/libsemanage/utils/semanage_migrate_store
>> >>> index 2e6cb278..50eb59ef 100755
>> >>> --- a/libsemanage/utils/semanage_migrate_store
>> >>> +++ b/libsemanage/utils/semanage_migrate_store
>> >>> @@ -15,10 +15,12 @@ sepol = ctypes.cdll.LoadLibrary('libsepol.so.1')
>> >>> try:
>> >>> import selinux
>> >>> import semanage
>> >>> -except:
>> >>> +except ImportError:
>> >>> print("You must install libselinux-python and libsemanage-python
>> >>> before running this tool", file=sys.stderr)
>> >>> exit(1)
>> >>> -
>> >>> +except Exception as e:
>> >>> + print("Failed to import libselinux-python/libsemanage-python: %s"
>> >>> % str(e))
>> >>> + exit(1)
>> >>>
>> >>
>> >> We should really only be handling exceptions we reasonably expect and
>> >> discourage
>> >> the usage of catching raw Exception, especially considering not-catching
>> >> this will
>> >> cause the runtime to print a stack trace, the error and exit non-zero.
>> >>
>> >> We probably only need the except ImportError change and can drop the
>> >> second
>> >> hunk.
>> >>
>> >> Does anyone disagree with this?
>>
>> For this case, I agree that ImportError is the only thing that should be
>> caught.
>>
>> > Agreed. catching Exception is bad cuz it also catches KeyboardInterrupt
>> > and stuff like that.
>>
>> That's not correct. Catching BaseException would catch
>> KeyboardInterrupt. Catching Exception would not. See the Python
>> builtin exception hierarchy:
>>
>> https://docs.python.org/3/library/exceptions.html#exception-hierarchy
>>
>> IMO catching Exception has valid uses.
>>
>> --
>> Chris PeBenito
___
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.
Re: [PATCH] libsemanage: improve semanage_migrate_store import failure
Yuli,
If you respin this with just import error looks like its a go.
Bill
On Fri, Oct 5, 2018 at 12:53 PM Chris PeBenito wrote:
> On 10/05/2018 10:32 AM, Jason Zaman wrote:
> > On Fri, Oct 05, 2018 at 07:13:23AM -0700, William Roberts wrote:
> >> On Thu, Oct 4, 2018 at 12:46 PM Yuli Khodorkovskiy <
> >> yuli.khodorkovs...@crunchydata.com> wrote:
> >>
> >>> The python module import error in semanage_migrate_store was
> misleading.
> >>> Before, it would print that the module is not installed, even though
> >>> it is in fact on the system.
> >>>
> >>> Now the python module import failure is correctly reported if the
> module
> >>> is not installed or the exact reason for failure is reported to the
> user.
> >>>
> >>> Signed-off-by: Yuli Khodorkovskiy
> >>> ---
> >>> libsemanage/utils/semanage_migrate_store | 6 --
> >>> 1 file changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/libsemanage/utils/semanage_migrate_store
> >>> b/libsemanage/utils/semanage_migrate_store
> >>> index 2e6cb278..50eb59ef 100755
> >>> --- a/libsemanage/utils/semanage_migrate_store
> >>> +++ b/libsemanage/utils/semanage_migrate_store
> >>> @@ -15,10 +15,12 @@ sepol = ctypes.cdll.LoadLibrary('libsepol.so.1')
> >>> try:
> >>> import selinux
> >>> import semanage
> >>> -except:
> >>> +except ImportError:
> >>> print("You must install libselinux-python and
> libsemanage-python
> >>> before running this tool", file=sys.stderr)
> >>> exit(1)
> >>> -
> >>> +except Exception as e:
> >>> + print("Failed to import libselinux-python/libsemanage-python:
> %s"
> >>> % str(e))
> >>> + exit(1)
> >>>
> >>
> >> We should really only be handling exceptions we reasonably expect and
> >> discourage
> >> the usage of catching raw Exception, especially considering not-catching
> >> this will
> >> cause the runtime to print a stack trace, the error and exit non-zero.
> >>
> >> We probably only need the except ImportError change and can drop the
> second
> >> hunk.
> >>
> >> Does anyone disagree with this?
>
> For this case, I agree that ImportError is the only thing that should be
> caught.
>
> > Agreed. catching Exception is bad cuz it also catches KeyboardInterrupt
> > and stuff like that.
>
> That's not correct. Catching BaseException would catch
> KeyboardInterrupt. Catching Exception would not. See the Python
> builtin exception hierarchy:
>
> https://docs.python.org/3/library/exceptions.html#exception-hierarchy
>
> IMO catching Exception has valid uses.
>
> --
> Chris PeBenito
>
___
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.
