On Sunday, April 24th, 2022 at 7:43 PM, James Ralston <ralston(a)pobox.com> 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.