Sensible labelling decisions and /usr/local/?

[RyanOblivion112]

Greetings everyone,

I'm currently cleaning up some automation scripts of mine and would like some assurance that the SELinux aspects of my changes are being handled sensibly.

As a part of this work I've decided it would be better to store various things in appropriate locations under "/usr/local/". While trying to understand the implications of this I've determined a few SELinux related concerns that I hope someone here can provide some insight on, these are:

01. I can see that the SELinux type for "/etc/"(etc_t) differs from that of "/usr/local/etc/"(usr_t), if I intend to actually utilize that directory would the "etc_t" label be more appropriate, if not why is that?

02. Adding onto the previous question what about files under "/usr/local/etc/", should their types be "usr_t" or is "etc_t" the more sensible decision?

Essentially I'd like to know if it's unwise to simply reuse the expected labels files and directories would have outside of "/usr/local/" within "/usr/local/".

[James Ralston]

Per the FHS (1), /usr/local is for use by the system administrator
when installing software locally.  Locally-installed software that is
not part of the core OS is not likely to have a preexisting SELinux
policy module and thus will run as unconfined_t, which means that the
SELinux file contexts on the /usr/local tree are unlikely to matter.

If you want to change this, you can always set equivalences, and then
re-label:

$ semanage fcontext -a -e /etc /usr/local/etc
$ restorecon -FR -v /usr/local
Relabeled /usr/local/etc from system_u:object_r:usr_t:s0 to
system_u:object_r:etc_t:s0

But again, the file contexts on files in /usr/local is probably just
not going to matter for 99.9% of things.

(1) https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

[RyanOblivion112]

On Sunday, April 24th, 2022 at 7:43 PM, James Ralston  wrote:
> Per the FHS (1), /usr/local is for use by the system administrator
> when installing software locally. Locally-installed software that is
> not part of the core OS is not likely to have a preexisting SELinux
> policy module and thus will run as unconfined_t, which means that the
> SELinux file contexts on the /usr/local tree are unlikely to matter.
>
> If you want to change this, you can always set equivalences, and then
> re-label:
>
> $ semanage fcontext -a -e /etc /usr/local/etc
> $ restorecon -FR -v /usr/local
> Relabeled /usr/local/etc from system_u:object_r:usr_t:s0 to
> system_u:object_r:etc_t:s0
>
> But again, the file contexts on files in /usr/local is probably just
> not going to matter for 99.9% of things.
>
> (1) https://refspecs.linuxfoundation.org/FHS_3.0/fhs/index.html

Thank you for the information.

My concerns are largely due to the data in /usr/local not being utilized in "isolation" from the core system by only other things in /usr/local. Imagine for example something run by pam_exec in a packaged service's PAM configuration file which is located in /usr/local/libexec. I suppose that in the end these are things I've intended to package anyway. As such it would probably be for that best to leave things the way they are since I lack the understanding of SELinux required for me to fully grasp any security implications such a change may have, even if they're very minor my goal isn't to make security any worse haha.