File context rule not working

File context rule not working

[Ian Pilcher]

I'm tearing my hair out trying to figure out why this rule isn't
matching.

   /usr(/local)?/bin/raidcheck    system_u:object_r:raidcheck_exec_t:s0

The rule shows up in the output of 'semanage fcontext -l', so it's
loaded, but either /usr/bin/raidcheck and /usr/local/bin/raidcheck  are
still being set to bin_t.

Is there any way to get restorecon to show the steps that it takes to
determine the context for a file?

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

Re: File context rule not working

[Nicolas Iooss]

On Sun, Jul 26, 2020 at 5:03 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>
> I'm tearing my hair out trying to figure out why this rule isn't
> matching.
>
>    /usr(/local)?/bin/raidcheck    system_u:object_r:raidcheck_exec_t:s0
>
> The rule shows up in the output of 'semanage fcontext -l', so it's
> loaded, but either /usr/bin/raidcheck and /usr/local/bin/raidcheck  are
> still being set to bin_t.
>
> Is there any way to get restorecon to show the steps that it takes to
> determine the context for a file?

Hello,
I guess this is due the rule 3 documented in
https://manpages.debian.org/experimental/libselinux1-dev/selabel_lookup_best_match_raw.3.en.html
(source https://github.com/SELinuxProject/selinux/blob/master/libselinux/man/man3/selabel_lookup_best_match.3):

    The order of precedence for best match is:
    1. An exact match for the real path (key) or
    2. An exact match for any of the links (aliases), or
    3. The longest fixed prefix match.

I guess that in your policy, there is a rule that states that
/usr/bin(/.*)? is labeled bin_t. As both /usr/bin(/.*)? and
/usr(/local)?/bin/raidcheck match /usr/bin/raidcheck, the order of
precedence is determined by the number of characters before the first
special characters (that indidate a regular expression). As
/usr/bin(/.*)? has a longer "fixed prefix", it is the one that
matches.

Does using "/usr/bin/raidcheck
system_u:object_r:raidcheck_exec_t:s0" fix your issue? If yes, you can
either duplicate the line (by adding both /usr/bin/... and
/usr/local/bin/...), or configure a substitution pattern such that
/usr/local/bin... gets transformed into /usr/bin/... before searching
for patterns.

Regards,
Nicolas

Re: File context rule not working

[Ian Pilcher]

On 7/26/20 11:01 AM, Nicolas Iooss wrote:
> I guess this is due the rule 3 documented in
> https://manpages.debian.org/experimental/libselinux1-dev/selabel_lookup_best_match_raw.3.en.html
> (source https://github.com/SELinuxProject/selinux/blob/master/libselinux/man/man3/selabel_lookup_best_match.3):
> 
>      The order of precedence for best match is:
>      1. An exact match for the real path (key) or
>      2. An exact match for any of the links (aliases), or
>      3. The longest fixed prefix match.
> 
> I guess that in your policy, there is a rule that states that
> /usr/bin(/.*)? is labeled bin_t. As both /usr/bin(/.*)? and
> /usr(/local)?/bin/raidcheck match /usr/bin/raidcheck, the order of
> precedence is determined by the number of characters before the first
> special characters (that indidate a regular expression). As
> /usr/bin(/.*)? has a longer "fixed prefix", it is the one that
> matches.

I can't find a '/usr/bin(/.*)?' rule.  'semanage fcontext --list' should
show it, right?

[root@n5550 files]# semanage fcontext --list | egrep '/usr/bin\('
/usr/lib/debug/usr/bin(/.*)?                       regular file 
system_u:object_r:bin_t:s0

But I suspect that your reasoning is still correct.  I wasn't aware of
the precedence rule.  The first "special character" does come pretty
early in my rule, so it's likely that something that's considered more
specific would match.

> Does using "/usr/bin/raidcheck
> system_u:object_r:raidcheck_exec_t:s0" fix your issue? If yes, you can
> either duplicate the line (by adding both /usr/bin/... and
> /usr/local/bin/...), or configure a substitution pattern such that
> /usr/local/bin... gets transformed into /usr/bin/... before searching
> for patterns.

'/usr/bin/raidcheck' and '/usr/local/bin/raidcheck' both work, so I'll
likely just go with that.

-- 
========================================================================
                  In Soviet Russia, Google searches you!
========================================================================

Re: File context rule not working

[Nicolas Iooss]

On Sun, Jul 26, 2020 at 8:01 PM Ian Pilcher <arequipeno@gmail.com> wrote:
>
> On 7/26/20 11:01 AM, Nicolas Iooss wrote:
> > I guess this is due the rule 3 documented in
> > https://manpages.debian.org/experimental/libselinux1-dev/selabel_lookup_best_match_raw.3.en.html
> > (source https://github.com/SELinuxProject/selinux/blob/master/libselinux/man/man3/selabel_lookup_best_match.3):
> >
> >      The order of precedence for best match is:
> >      1. An exact match for the real path (key) or
> >      2. An exact match for any of the links (aliases), or
> >      3. The longest fixed prefix match.
> >
> > I guess that in your policy, there is a rule that states that
> > /usr/bin(/.*)? is labeled bin_t. As both /usr/bin(/.*)? and
> > /usr(/local)?/bin/raidcheck match /usr/bin/raidcheck, the order of
> > precedence is determined by the number of characters before the first
> > special characters (that indidate a regular expression). As
> > /usr/bin(/.*)? has a longer "fixed prefix", it is the one that
> > matches.
>
> I can't find a '/usr/bin(/.*)?' rule.  'semanage fcontext --list' should
> show it, right?
>
> [root@n5550 files]# semanage fcontext --list | egrep '/usr/bin\('
> /usr/lib/debug/usr/bin(/.*)?                       regular file
> system_u:object_r:bin_t:s0

Yes, on my system (that uses refpolicy):

# semanage fcontext --list | egrep '/usr/bin\('
/usr/bin(/.*)?                                     all files
system_u:object_r:bin_t

> But I suspect that your reasoning is still correct.  I wasn't aware of
> the precedence rule.  The first "special character" does come pretty
> early in my rule, so it's likely that something that's considered more
> specific would match.
>
> > Does using "/usr/bin/raidcheck
> > system_u:object_r:raidcheck_exec_t:s0" fix your issue? If yes, you can
> > either duplicate the line (by adding both /usr/bin/... and
> > /usr/local/bin/...), or configure a substitution pattern such that
> > /usr/local/bin... gets transformed into /usr/bin/... before searching
> > for patterns.
>
> '/usr/bin/raidcheck' and '/usr/local/bin/raidcheck' both work, so I'll
> likely just go with that.

Great! Glad I could help fix your issue.

Cheers,
Nicolas

Re: File context rule not working

[Dominick Grift]

Ian Pilcher <arequipeno@gmail.com> writes:

> I'm tearing my hair out trying to figure out why this rule isn't
> matching.
>
>   /usr(/local)?/bin/raidcheck    system_u:object_r:raidcheck_exec_t:s0

Some suggestions in order of likelyness.

It might be that due to the (/local)? part another entry that is more
specific takes precedence. (try splitting the spec into two lines, or
even better make /usr/local/bin the equivalence of /usr/bin). You might
also be able to make it make it more specific by adding the -- filespec,
which you probably should have done anyway (always be as specific as
possible):

/usr(/local)?/bin/raidcheck -- system_u:object_r:raidcheck_exec_t:s0

Maybe these are hardlinks?

Maybe there are equivalence rules in place for these locations. Then you
would have to make the spec apply to the location of which this location
is the equivalence.

>
> The rule shows up in the output of 'semanage fcontext -l', so it's
> loaded, but either /usr/bin/raidcheck and /usr/local/bin/raidcheck  are
> still being set to bin_t.
>
> Is there any way to get restorecon to show the steps that it takes to
> determine the context for a file?

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
https://sks-keyservers.net/pks/lookup?op=get&search=0xDA7E521F10F64098
Dominick Grift