Restricting Access to Files when Standard Linux Permissions Won't Suffice

Question

I administer several RHEL 6.9 systems. On each system, a particular directory, call it /app_dir, is the top level of where our project's scripts, executables, configuration files, and logs are stored. The tree under this top-level directory is broad and deep. All files and subdirectories under /app_dir are owned by user user1 and have group membership of group1. Human users always run as user1, and user1's primary group is group1.

Some systems are for manufacturing team members to test the hardware widgets we produce before delivery to a customer, and some systems are for development of the software used to test the hardware widgets.

All human users log into a GNOME desktop as user1. Our main (GUI) application is then run by opening a terminal and launching the application from the command line.

The manufacturing systems need to stay in a pristine state. However, for various reasons, developers will change a script or configuration file to test something on a manufacturing system and forget to revert the change. A classic problem.

Then, when a production team member uses the system, it either won't work at all, it will give a false pass (this is the worst case because it causes us to deliver a faulty hardware widget), or it will give a false fail (causing lost revenue from not delivering a hardware widget that was, in fact, suitable for delivery).

So, I need to find a way to lock down (i.e. make readable but not writable) the scripts and configuration files in our directory structure so that, with a handful of well-defined exceptions, they cannot be changed except by a lead that has special privileges. Standard Linux permissions are inadequate since, given what's described in the first paragraph of this post, they allow any human user (who always runs as user1) to change any file at will.

At this point in our lifecycle, we unfortunately don't have the flexibility to change much in terms of directory structure, users, groups, etc.

I'm thinking SELinux will provide a solution.

The actual situation is much more complex, but as an example, consider this directory structure:

/app_dir/bin/
/app_dir/bin/widget_tester
/app/dir/bin/<other executables>

/app_dir/config/
/app_dir/config/widget_info.txt
/app_dir/config/test_tolerances.txt
/app_dir/config/<other configuration files>

/app_dir/scripts/
/app_dir/scripts/script_1.py
/app_dir/scripts/script_2.sh
/app_dir/scripts/<other scripts>

/app_dir/logs/
/app_dir/logs/<log files>

/app_dir/bin/, and everything under it, should be locked down without exceptions.

/app_dir/config/, and everything under it, should be locked down with the exception of widget_info.txt. A manufacturing team member needs to be able to provide information about the hardware widget that's about to be tested.

/app_dir/scripts/, and everything under it, should be locked down with the exception of script_1.py.

/app_dir/logs/, and everything under it, should be writable by our executables and scripts, but for humans (i.e. user1), it should only by readable.

Is SELinux the right tool for this job? If so, are types / type enforcement the mechanism to use? if no to either, where else would I best focus my learning efforts?

UPDATE 1

Please note that the setup I've described of having all humans run as user1 predates my arrival on the project by, literally, years. I understand that it has its shortcomings (but there actually are valid reasons for it that I need not get into here). This is a real-world manufacturing operation. A restructuring of our setup is completely infeasible from a business perspective. It would not be allowed by management.

I point this out to stress that I'm not requesting a critique of our current setup. I am trying to find out from community experts who know more about SELinux than I if I'm barking up the right or wrong tree by spending my efforts learning about SELinux. I'm also requesting pointers to other Linux mechanisms I may not know about that may solve this problem. (i.e., though my current focus is SELinux, I don't want to necessarily limit the discussion to SELinux.)

Answer 1

Use the "chattr" command to give the selected files/folders the "immutable" attribute. No one will be able to modify those files, not even the file owner or the root user until the attribute is removed by root.

Answer 2

These are simple permissions issue, SeLinux wont help in this case :

ACL : is an additional and more flexible permission mechanism for file systems.

What you have to do here is to simply give for each user / group the permissions they need on the files :

1- First, check if your filesystems supports ACLs (e.g xfs, ext2, ext3, ext4) :

2- Set the ownership of /app_dir/* to leaduser, so the lead is the only one having the full control over it :

chown -R lead:lead /app_dir/

OR

If you want to keep using user1 & group1 because the that's how the application should be started with, then add leaduser to group1 as a secondary group :

usermod -G group1 leaduser

3- Set the exceptions by setting ACLS on directories / files.

E.g : /app_dir/bin/

setfacl -Rm g:devgroup:rx /app_dir/bin/
setfacl -Rm g:manufactgroup:rx /app_dir/bin/

P.S : R is for recursive.

3- Check that ACLs were applied correctly :

getfacl /app_dir/bin/

Here is a great article that will help setting the correct ACLs for the remaining paths