2

I have a solution that is being installed in an enterprise environment. The solution and its deployment guide are designed to installed on a RHEL7/CentOS7 server with SELinux enabled and components being installed to locations according to the Filesystem Hierarchy Standard.

One of the clients however has surprised us by stating that all 3rd party solutions must be installed to a /apps directory since they back this up according to policy.

To avoid deviation for this specific client, since it would require significant modifications to the solution, we decided the best approach would be to create a new directory in the /apps directory for /optand create symlinks upfront from the true /opt and apply the same SELinux content to it (usr_t) e.g.:

ls -laZ /appl/opt
drwxr-xr-x. root     root     unconfined_u:object_r:usr_t:s0   .
drwxr-xr-x. root     root     unconfined_u:object_r:default_t:s0 ..
drwxr-xr-x. product product unconfined_u:object_r:usr_t:s0   product

la -laZ /opt
drwxr-xr-x. root root system_u:object_r:usr_t:s0       .
dr-xr-xr-x. root root system_u:object_r:root_t:s0      ..
lrwxrwxrwx. root root unconfined_u:object_r:usr_t:s0   product -> /apps/opt/product/

Certain components of the product are accessed via Apache HTTPD and require the httpd_sys_content_t context to be applied to them.

The files are located at /opt/product/wwwstatic/ (which in reality is /apps/opt/product/wwwstatic/).

The deployment guide specifies the following commands to run:

semanage fcontext -a -t httpd_sys_content_t "/opt/product/wwwstatic/*"
restorecon -Rv /opt/product/wwwstatic

which restores the contexts on a standard installation but in this environment, because of the symlinks, it fails.

If you modify the commands to include the /apps directory it works but deviates from a generic approach.

The contents of /etc/selinux/targeted/contexts/files/file_contexts.local is:

# This file is auto-generated by libsemanage
# Do not edit directly.

/appl/opt/.*    system_u:object_r:usr_t:s0
/appl/srv/.*    system_u:object_r:var_t:s0
/opt/product/wwwstatic/*    system_u:object_r:httpd_sys_content_t:s0

Is there a means of modifying the arguments to semanage or restorecon commands so that this will work for symlinks (as well as normally) or have I a fundamental misunderstanding of how SELinux applies file contexts?

I believe this question differs from How do I assign an SELinux label to a symlink with semanage so it persists after a relabel? since it is about applying contexts to files in subdirectories from symlinked directories instead of applying contexts to the symlink file itself.

Community
  • 1
prcjac
  • 23
  • 1
  • 6

3 Answers3

5

You could use the realpath command in the deployment guide to ensure the instructions are generic but apply the contexts to the real filesystem location where ever that may actually be be.

`realpath "/opt/product/wwwstatic"`
Stephen White
  • 68
  • 4
3

SELinux file contexts match based on the actual filesystem path. There is no "follow symlinks". So your custom contexts need to reference the actual location on disk.

The standard location for third party applications is /opt, so you are correct here. If you have a client that wants to do something nonstandard, then you should make it clear to them that they're doing it wrong, and what the additional costs (in time and money) of that will be.

Michael Hampton
  • 237,123
  • 42
  • 477
  • 940
-1

Use the -h flag with chcon:

chcon -h -v system_u:object_r:httpd_sys_content_t:s0 *

NightKnight on Cloudinsidr.com
  • 49
  • 4
  • Don't use this one folks, it won't survive a reboot or a restorecon. Use `semanage fcontext -a -t type pattern` and restorecon the file/directory afterwards. The pattern needs to match the actual location on the file system, not path via symlink. – Lester Peabody Aug 12 '22 at 15:12