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.)