SELinux Archive on lore.kernel.org
 help / color / Atom feed
* File context rule not working
@ 2020-07-26 15:03 Ian Pilcher
  2020-07-26 16:01 ` Nicolas Iooss
  2020-07-26 16:03 ` Dominick Grift
  0 siblings, 2 replies; 5+ messages in thread
From: Ian Pilcher @ 2020-07-26 15:03 UTC (permalink / raw)
  To: SElinux list

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!
========================================================================

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: File context rule not working
  2020-07-26 15:03 File context rule not working Ian Pilcher
@ 2020-07-26 16:01 ` Nicolas Iooss
  2020-07-26 18:01   ` Ian Pilcher
  2020-07-26 16:03 ` Dominick Grift
  1 sibling, 1 reply; 5+ messages in thread
From: Nicolas Iooss @ 2020-07-26 16:01 UTC (permalink / raw)
  To: Ian Pilcher; +Cc: SElinux list

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: File context rule not working
  2020-07-26 15:03 File context rule not working Ian Pilcher
  2020-07-26 16:01 ` Nicolas Iooss
@ 2020-07-26 16:03 ` Dominick Grift
  1 sibling, 0 replies; 5+ messages in thread
From: Dominick Grift @ 2020-07-26 16:03 UTC (permalink / raw)
  To: Ian Pilcher; +Cc: SElinux list

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

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: File context rule not working
  2020-07-26 16:01 ` Nicolas Iooss
@ 2020-07-26 18:01   ` Ian Pilcher
  2020-07-26 18:52     ` Nicolas Iooss
  0 siblings, 1 reply; 5+ messages in thread
From: Ian Pilcher @ 2020-07-26 18:01 UTC (permalink / raw)
  To: Nicolas Iooss; +Cc: SElinux list

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!
========================================================================

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: File context rule not working
  2020-07-26 18:01   ` Ian Pilcher
@ 2020-07-26 18:52     ` Nicolas Iooss
  0 siblings, 0 replies; 5+ messages in thread
From: Nicolas Iooss @ 2020-07-26 18:52 UTC (permalink / raw)
  To: Ian Pilcher; +Cc: SElinux list

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


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, back to index

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-07-26 15:03 File context rule not working Ian Pilcher
2020-07-26 16:01 ` Nicolas Iooss
2020-07-26 18:01   ` Ian Pilcher
2020-07-26 18:52     ` Nicolas Iooss
2020-07-26 16:03 ` Dominick Grift

SELinux Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux/0 selinux/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux selinux/ https://lore.kernel.org/selinux \
		selinux@vger.kernel.org
	public-inbox-index selinux

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git