restorecon ignoring my policy

[Sam Varshavchik]

Something happened with the most recent selinux update in F41, breaking my  
local policy.

[root@jack ~]# semanage fcontext -l | grep httportmapd
/usr/sbin/httportmapd                              regular file        
system_u:object_r:libcxx_httportmapd_exec_t:s0

This is coming from a local policy module I cobbled together and installed,  
yet:

[root@jack ~]# ls -alZ /usr/sbin/httportmapd
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 318104 Sep 21  2018  
/usr/sbin/httportmapd

And restorecon -F /usr/sbin/httportmapd does not fix the context, and stays  
silent no matter how many -v options I feed to it.

Any idea why my file context is not being used?

[Sam Varshavchik]

> Something happened with the most recent selinux update in F41, breaking my  
> local policy.
>
> [root@jack ~]# semanage fcontext -l | grep httportmapd
> /usr/sbin/httportmapd                              regular file        
> system_u:object_r:libcxx_httportmapd_exec_t:s0
>
> This is coming from a local policy module I cobbled together and installed,  
> yet:
>
> [root@jack ~]# ls -alZ /usr/sbin/httportmapd
> -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 318104 Sep 21  2018  
> /usr/sbin/httportmapd
>
> And restorecon -F /usr/sbin/httportmapd does not fix the context, and stays  
> silent no matter how many -v options I feed to it.
>
> Any idea why my file context is not being used?

This looks like a bigger issue, and not just with my module.

There's another explicit file context set for /usr/sbin/smartd. semanage  
says:

/usr/sbin/smartd                                   regular file       system_u:object_r:fsdaemon_exec_t:s0

However:

[root@jack ~]# ls -alZ /usr/sbin/smartd
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 671608 Jul 19 20:00 /usr/sbin/smartd

And restorecon thinks this is peachy.

I note that semanage fcontext lists, separately:

/usr/sbin = /usr/bin

Not sure if this is related, or not. I do see stuff in /usr/sbin with other  
labels, namely /usr/sbin/xl2tpd. I don't see how it's set, this does not  
appear in the output of semanage fcontext.

[David Sastre Medina]

Seems to be a problem with a substitution alias.
Contexts potentially affected:

```
$ rg ^/usr/sbin /etc/selinux/targeted/contexts/files/file_contexts
4104:/usr/sbin/tlshd    --      system_u:object_r:ktlshd_exec_t:s0
4304:/usr/sbin/nbdkit   --      system_u:object_r:nbdkit_exec_t:s0
4305:/usr/sbin/smartd   --      system_u:object_r:fsdaemon_exec_t:s0
5663:/usr/sbin/rhel-push-plugin --
 system_u:object_r:container_runtime_exec_t:s0
5749:/usr/sbin/pcm-sensor-server        --
 system_u:object_r:pcmsensor_exec_t:s0
```

And the culprit would be an aliasing rule:

```
$ rg bin /etc/selinux/targeted/contexts/files/file_contexts.subs_dist
29:/sbin                /usr/bin
33:/bin                 /usr/bin
34:/usr/sbin            /usr/bin # <-----------
```

According to selabel_file(5):

Substitution File Format
       Each line within the substitution files (.subs and .subs_dist) has
the form:
              subs_pathname pathname

Where:
              pathname
                     A path that matches an entry in one or more of the
file contexts policy configuration file.
              subs_pathname
                     The path that will be aliased (considered equivalent)
with pathname by the look up process.

Example:
              # ./contexts/files/file_contexts.subs
              # pathname  subs_pathname
              /myweb      /var/www
              /myspool    /var/spool/mail

Using the above example, when selabel_lookup(3) is passed a
path of /myweb/index.html the function will substitute the /myweb  component
              with /var/www, therefore the path used is:

/var/www/index.html

Assuming (I haven't checked, I could be wrong) `restorecon` uses labels
returned by `selabel_lookup`, it makes sense it thinks the context is
correct.

On Sat, Dec 28, 2024 at 2:28 PM Sam Varshavchik via selinux <
[e-mail]> wrote:
> > Something happened with the most recent selinux update in F41, breaking
>
> my
> > local policy.
> >
> > [root@jack ~]# semanage fcontext -l | grep httportmapd
> > /usr/sbin/httportmapd                              regular file
> > system_u:object_r:libcxx_httportmapd_exec_t:s0
> >
> > This is coming from a local policy module I cobbled together and
>
> installed,
> > yet:
> >
> > [root@jack ~]# ls -alZ /usr/sbin/httportmapd
> > -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 318104 Sep 21  2018
> > /usr/sbin/httportmapd
> >
> > And restorecon -F /usr/sbin/httportmapd does not fix the context, and
>
> stays
> > silent no matter how many -v options I feed to it.
> >
> > Any idea why my file context is not being used?
>
> This looks like a bigger issue, and not just with my module.
>
> There's another explicit file context set for /usr/sbin/smartd. semanage
> says:
>
> /usr/sbin/smartd                                   regular file
>  system_u:object_r:fsdaemon_exec_t:s0
>
> However:
>
> [root@jack ~]# ls -alZ /usr/sbin/smartd
> -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 671608 Jul 19 20:00
> /usr/sbin/smartd
>
> And restorecon thinks this is peachy.
>
> I note that semanage fcontext lists, separately:
>
> /usr/sbin = /usr/bin
>
> Not sure if this is related, or not. I do see stuff in /usr/sbin with
> other
> labels, namely /usr/sbin/xl2tpd. I don't see how it's set, this does not
> appear in the output of semanage fcontext.
>
> --
> _______________________________________________
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Sam Varshavchik]

David Sastre Medina via selinux writes:
> Contexts potentially affected:
> $ rg ^/usr/sbin /etc/selinux/targeted/contexts/files/file_contexts
> 4104:/usr/sbin/tlshd    --      system_u:object_r:ktlshd_exec_t:s0
> 4304:/usr/sbin/nbdkit   --      system_u:object_r:nbdkit_exec_t:s0
> 4305:/usr/sbin/smartd   --      system_u:object_r:fsdaemon_exec_t:s0
> 5663:/usr/sbin/rhel-push-plugin --      
>  system_u:object_r:container_runtime_exec_t:s0
> 5749:/usr/sbin/pcm-sensor-server        --      
>  system_u:object_r:pcmsensor_exec_t:s0
>
> And the culprit would be an aliasing rule:
> $ rg bin /etc/selinux/targeted/contexts/files/file_contexts.subs_dist
> 29:/sbin                /usr/bin
> 33:/bin                 /usr/bin
> 34:/usr/sbin            /usr/bin # <-----------
> Assuming (I haven't checked, I could be wrong) `restorecon` uses labels  
> returned by `selabel_lookup`, it makes sense it thinks the context is  
> correct.

Something other than restorecon got changed. I did not start getting AVCs  
until I installed a week's worth of updates.

dnf history shows that I installed version 0:41.27-1 of selinux policy  
packages. I had no issues prior to installing this update.

It appears that many packages are already aware of this …feature. The abrt- 
dbus package, for example, installs /usr/sbin/abrt-dbus, but includes a  
label for:

[root@jack ~]# semanage fcontext --list | grep abrt_exec_t
/usr/bin/abrt-dbus                                 regular file       system_u:object_r:abrt_exec_t:s0

This is very confusing.

[David Sastre Medina]

I didn't mean to imply that `restorecon` has changed, rather that it's
working as expected.

I think the /usr/sbin -> /usr/bin addition to file_contexts.subs_dist is
related to
https://discussion.fedoraproject.org/t/f40-change-proposal-unify-usr-bin-and...

Reading the changelog of the selinux-policy RPM, you can read that:
- Alias /usr/sbin to /usr/bin and change all /usr/sbin paths to /usr/bin

was implemented in 41.4-1. Depending on which version you upgraded from,
that may be proof.

Adding "fake" labels for files installed under `/usr/sbin` using `/usr/bin`
in the file contexts is just hiding the problem.

On Sun, Dec 29, 2024 at 5:44 PM Sam Varshavchik via selinux <
[e-mail]> wrote:
> David Sastre Medina via selinux writes:
> > Contexts potentially affected:
> > $ rg ^/usr/sbin /etc/selinux/targeted/contexts/files/file_contexts
> > 4104:/usr/sbin/tlshd    --      system_u:object_r:ktlshd_exec_t:s0
> > 4304:/usr/sbin/nbdkit   --      system_u:object_r:nbdkit_exec_t:s0
> > 4305:/usr/sbin/smartd   --      system_u:object_r:fsdaemon_exec_t:s0
> > 5663:/usr/sbin/rhel-push-plugin --
> >  system_u:object_r:container_runtime_exec_t:s0
> > 5749:/usr/sbin/pcm-sensor-server        --
> >  system_u:object_r:pcmsensor_exec_t:s0
> >
> > And the culprit would be an aliasing rule:
> > $ rg bin /etc/selinux/targeted/contexts/files/file_contexts.subs_dist
> > 29:/sbin                /usr/bin
> > 33:/bin                 /usr/bin
> > 34:/usr/sbin            /usr/bin # <-----------
> > Assuming (I haven't checked, I could be wrong) `restorecon` uses labels
> > returned by `selabel_lookup`, it makes sense it thinks the context is
> > correct.
>
> Something other than restorecon got changed. I did not start getting AVCs
> until I installed a week's worth of updates.
>
> dnf history shows that I installed version 0:41.27-1 of selinux policy
> packages. I had no issues prior to installing this update.
>
> It appears that many packages are already aware of this …feature. The
> abrt-
> dbus package, for example, installs /usr/sbin/abrt-dbus, but includes a
> label for:
>
> [root@jack ~]# semanage fcontext --list | grep abrt_exec_t
> /usr/bin/abrt-dbus                                 regular file
>  system_u:object_r:abrt_exec_t:s0
> This is very confusing.
>
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Sam Varshavchik]

David Sastre Medina via selinux writes:
> I think the /usr/sbin -> /usr/bin addition to file_contexts.subs_dist is  
> related to <URL:https://discussion.fedoraproject.org/t/f40-change-proposal- 
> unify-usr-bin-and-usr-sbin-system-wide/ 
> 99853>https://discussion.fedoraproject.org/t/f40-change-proposal-unify-usr- 
> bin-and-usr-sbin-system-wide/99853

I remembered that while I was trying to figure out this Scooby Doo mystery,  
yesterday. I checked and /usr/sbin is not a symlink yet, as was proposed  
there, so I figured that the proposal wasn't fully baked.

Still, this nagged in my mind. I decided to see what "semanage fcontext"  
knows about /usr/sbin/* and, it didn't seem to know much. I looked there. I  
saw plenty of stuff with labels. Digging through what "semanage fcontext"  
was telling me I found those labels had entries with the /usr/bin prefix,  
which were, of course, referring to nonexistent files. I tried setting the  
label for my /usr/sbin binary via /usr/bin and it worked. I felt dirty.

I did see, early in my adventures, that fcontext terminated its braindump  
with "/usr/sbin = /usr/bin". I could not find anything in the semanage- 
fcontext man page that explained the output, but it sort of gave me a vague,  
general idea, of something like that, which prompted me to look closer at  
the rules, and eventually figure it out.
> Reading the changelog of the selinux-policy RPM, you can read that:
> Alias /usr/sbin to /usr/bin and change all /usr/sbin paths to /usr/bin
>
> was implemented in 41.4-1. Depending on which version you upgraded from, that  
> may be proof.

According to dnf history I updated from 41.26. I can only say that I started  
to get AVCs after this update and I am pretty confident of that. The  
consequence of the AVC was an hourly spam in my mailbox, which was pretty  
loud, and it definitely started then, and not whenever I updated from 41.4.

The alias might've been introduced in that version, but up until the latest  
update it seems that the alias's handling was much more robust, and it's now  
…less robust. In addition to selinux-policy, I updated glibc and the kernel.

I almost forgot to mention: my /var/run labels were also broken in my policy  
module. For an almost identical reason (except that /var/run is a real  
symlink to /run, so this alias at least makes a little bit more sense).

[Zdenek Pytela]

On Sun, Dec 29, 2024 at 10:02 PM Sam Varshavchik via selinux <
[e-mail]> wrote:
> David Sastre Medina via selinux writes:
> > I think the /usr/sbin -> /usr/bin addition to file_contexts.subs_dist
>
> is
> > related to <URL:
>
> https://discussion.fedoraproject.org/t/f40-change-proposal-
> > unify-usr-bin-and-usr-sbin-system-wide/
> > 99853>
>
> https://discussion.fedoraproject.org/t/f40-change-proposal-unify-usr-
> > bin-and-usr-sbin-system-wide/99853

Correct, the active link for the change is
https://fedoraproject.org/wiki/Changes/Unify_bin_and_sbin

selinux-policy complies to this since Fedora 41 (June to September).
A part of the package there is a script to convert local entries to a
selinux module. It can be debugged with

DEBUG=yes /usr/libexec/selinux/binsbin-convert.sh targeted

and subsequently the content of /run/selinux-policy checked. If the script
does not work, please report a bug.
Anyway, the long term solution is to change the entries to use /usr/bin.
> I remembered that while I was trying to figure out this Scooby Doo
> mystery,
> yesterday. I checked and /usr/sbin is not a symlink yet, as was proposed
> there, so I figured that the proposal wasn't fully baked.
>
> Still, this nagged in my mind. I decided to see what "semanage fcontext"
> knows about /usr/sbin/* and, it didn't seem to know much. I looked there.
> I
> saw plenty of stuff with labels. Digging through what "semanage fcontext"
> was telling me I found those labels had entries with the /usr/bin prefix,
> which were, of course, referring to nonexistent files. I tried setting
> the
> label for my /usr/sbin binary via /usr/bin and it worked. I felt dirty.
>
> I did see, early in my adventures, that fcontext terminated its braindump
> with "/usr/sbin = /usr/bin". I could not find anything in the semanage-
> fcontext man page that explained the output, but it sort of gave me a
> vague,
> general idea, of something like that, which prompted me to look closer at
> the rules, and eventually figure it out.
> > Reading the changelog of the selinux-policy RPM, you can read that:
> > Alias /usr/sbin to /usr/bin and change all /usr/sbin paths to /usr/bin
> > was implemented in 41.4-1. Depending on which version you upgraded from,
>
> that
> > may be proof.
>
> According to dnf history I updated from 41.26. I can only say that I
> started
> to get AVCs after this update and I am pretty confident of that. The
> consequence of the AVC was an hourly spam in my mailbox, which was pretty
> loud, and it definitely started then, and not whenever I updated from 41.4.
>
> The alias might've been introduced in that version, but up until the
> latest
> update it seems that the alias's handling was much more robust, and it's
> now
> …less robust. In addition to selinux-policy, I updated glibc and the
> kernel.
>
> I almost forgot to mention: my /var/run labels were also broken in my
> policy
> module. For an almost identical reason (except that /var/run is a real
> symlink to /run, so this alias at least makes a little bit more sense).

Similarly, the /var/run=/run equivalency was inverted and all entries were
changed in F40 before its GA
and there also is a conversion script in place.
Local policy should use /run.
> --
> _______________________________________________
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Sam Varshavchik]

Zdenek Pytela writes:
> Anyway, the long term solution is to change the entries to use /usr/bin.

So, right now:

1. A package installs stuff in /usr/sbin
2. It installs an selinux policy file referencing filenames in /usr/bin

Am I the only one who has …questions, here?

[Zdenek Pytela]

On Fri, Jan 3, 2025 at 6:01 PM Sam Varshavchik via selinux <
[e-mail]> wrote:
> Zdenek Pytela writes:
> > Anyway, the long term solution is to change the entries to use /usr/bin.
>
> So, right now:
> A package installs stuff in /usr/sbin
> It installs an selinux policy file referencing filenames in /usr/bin
>
> Am I the only one who has …questions, here?

Firstly, there is an equivalency supporting the change:

f42# semanage fcontext -l | grep /usr/sbin.=
/usr/sbin = /usr/bin
f42# ls -Z /usr/sbin/sshd
system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd
f42# matchpathcon /usr/sbin/sshd
/usr/sbin/sshd  system_u:object_r:sshd_exec_t:s0

Equivalency is a feature to substitute one path in the policy with another.
Secondly, there is a script to take care of all entries referring to
/usr/sbin, e. g. from a local policy module. Feel free to file a bug report
if an improvement is needed.
> --
> _______________________________________________
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[David Sastre Medina]

Hello Zdenek,

There are a few executables that are not being properly labelled, and
restorecon does not correct it.
I don't have any custom policy installed in this system.
This is one example:

$ sudo semanage fcontext -l | rg /usr/sbin/smartd
/usr/sbin/smartd                                   regular file
system_u:object_r:fsdaemon_exec_t:s0
$ ls -lZ /usr/sbin/smartd
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 671608 Jul 20 02:00
/usr/sbin/smartd

$ sudo restorecon -v /usr/sbin/smartd
$ ls -lZ /usr/sbin/smartd
-rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 671608 Jul 20 02:00
/usr/sbin/smartd

The other executables potentially affected by the same problem (I cannot
check, I don't have any of them installed), are:

$ sudo semanage fcontext -l | rg /usr/sbin/
/usr/sbin/nbdkit                                   regular file
system_u:object_r:nbdkit_exec_t:s0
/usr/sbin/pcm-sensor-server                        regular file
system_u:object_r:pcmsensor_exec_t:s0
/usr/sbin/rhel-push-plugin                         regular file
system_u:object_r:container_runtime_exec_t:s0
/usr/sbin/smartd                                   regular file
system_u:object_r:fsdaemon_exec_t:s0
/usr/sbin/tlshd                                    regular file
system_u:object_r:ktlshd_exec_t:s0

Let me know if you need a bug opened for this, and where (GitHub, BZ, ...)

Regards.

On Thu, Jan 9, 2025 at 6:57 PM Zdenek Pytela via selinux <
[e-mail]> wrote:
> On Fri, Jan 3, 2025 at 6:01 PM Sam Varshavchik via selinux <
> [e-mail]> wrote:
> > Zdenek Pytela writes:
> > > Anyway, the long term solution is to change the entries to use /usr/bin.
> >
> > So, right now:
> > A package installs stuff in /usr/sbin
> > It installs an selinux policy file referencing filenames in /usr/bin
> >
> > Am I the only one who has …questions, here?
>
> Firstly, there is an equivalency supporting the change:
>
> f42# semanage fcontext -l | grep /usr/sbin.=
> /usr/sbin = /usr/bin
> f42# ls -Z /usr/sbin/sshd
> system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd
> f42# matchpathcon /usr/sbin/sshd
> /usr/sbin/sshd  system_u:object_r:sshd_exec_t:s0
>
> Equivalency is a feature to substitute one path in the policy with another.
> Secondly, there is a script to take care of all entries referring to
> /usr/sbin, e. g. from a local policy module. Feel free to file a bug report
> if an improvement is needed.
> > --
> > _______________________________________________
> > selinux mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]...
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue
>
> --
>
> Zdenek Pytela
> Security SELinux team
> --
> _______________________________________________
> selinux mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Zdenek Pytela]

On Thu, Jan 9, 2025 at 7:28 PM David Sastre Medina <
[e-mail]> wrote:
> Hello Zdenek,
>
> There are a few executables that are not being properly labelled, and
> restorecon does not correct it.
> I don't have any custom policy installed in this system.
> This is one example:
>
> $ sudo semanage fcontext -l | rg /usr/sbin/smartd
> /usr/sbin/smartd                                   regular file
> system_u:object_r:fsdaemon_exec_t:s0
> $ ls -lZ /usr/sbin/smartd
> -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 671608 Jul 20 02:00
> /usr/sbin/smartd
>
> $ sudo restorecon -v /usr/sbin/smartd
> $ ls -lZ /usr/sbin/smartd
> -rwxr-xr-x. 1 root root system_u:object_r:bin_t:s0 671608 Jul 20 02:00
> /usr/sbin/smartd
>
> The other executables potentially affected by the same problem (I cannot
> check, I don't have any of them installed), are:
>
> $ sudo semanage fcontext -l | rg /usr/sbin/
> /usr/sbin/nbdkit                                   regular file
> system_u:object_r:nbdkit_exec_t:s0
> /usr/sbin/pcm-sensor-server                        regular file
> system_u:object_r:pcmsensor_exec_t:s0
> /usr/sbin/rhel-push-plugin                         regular file
> system_u:object_r:container_runtime_exec_t:s0
> /usr/sbin/smartd                                   regular file
> system_u:object_r:fsdaemon_exec_t:s0
> /usr/sbin/tlshd                                    regular file
> system_u:object_r:ktlshd_exec_t:s0
>
> Let me know if you need a bug opened for this, and where (GitHub, BZ, ...)

David,
thanks for the report, no need for an action now. Some of them were fixed
just a while ago, the others need some attention to find out what makes
them different from other entries which work fine. nbdkit and smartmontools
ship their own policy and it needs to be changed there.
It should also be fixed on selinux-policy update or when the script is run
manually; that's certainly meant as a temporary measure only.
> Regards.
>
> On Thu, Jan 9, 2025 at 6:57 PM Zdenek Pytela via selinux <
> [e-mail]> wrote:
> > On Fri, Jan 3, 2025 at 6:01 PM Sam Varshavchik via selinux <
> > [e-mail]> wrote:
> > > Zdenek Pytela writes:
> > > > Anyway, the long term solution is to change the entries to use
> > >
> > > /usr/bin.
> > >
> > > So, right now:
> > > A package installs stuff in /usr/sbin
> > > It installs an selinux policy file referencing filenames in /usr/bin
> > >
> > > Am I the only one who has …questions, here?
> >
> > Firstly, there is an equivalency supporting the change:
> >
> > f42# semanage fcontext -l | grep /usr/sbin.=
> > /usr/sbin = /usr/bin
> > f42# ls -Z /usr/sbin/sshd
> > system_u:object_r:sshd_exec_t:s0 /usr/sbin/sshd
> > f42# matchpathcon /usr/sbin/sshd
> > /usr/sbin/sshd  system_u:object_r:sshd_exec_t:s0
> >
> > Equivalency is a feature to substitute one path in the policy with
> > another.
> > Secondly, there is a script to take care of all entries referring to
> > /usr/sbin, e. g. from a local policy module. Feel free to file a bug report
> > if an improvement is needed.
> > > --
> > > _______________________________________________
> > > selinux mailing list -- [e-mail]
> > > To unsubscribe send an email to [e-mail]
> > > Fedora Code of Conduct:
> > > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > > List Archives:
> > > https://lists.fedoraproject.org/archives/list/[e-mail]...
> > > Do not reply to spam, report it:
> > > https://pagure.io/fedora-infrastructure/new_issue
> >
> > --
> >
> > Zdenek Pytela
> > Security SELinux team
> > --
> > _______________________________________________
> > selinux mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/[e-mail]...
> > Do not reply to spam, report it:
> > https://pagure.io/fedora-infrastructure/new_issue