Review permissions for proper tool functioning

[pleia2]

We're giving the "apache" user pretty broad permissions (ownership of the whole tool) in our installation documentation, but more restricted permissions may also work, and be more appropriate from a best practices perspective.

Investigate by restricting permissions significantly and adjust documentation accordingly.

[rachejazz]

For the tool to work and log printing, apache user should have read and write permissions and for the binaries to work, it should have execute permissions. The most we can do is remove sudo permissions which it already doesn't. What else could be done?

[pleia2]

At first glance, I think only the data_files/ directory really needs to be writable by the apache user since that's what is being modified, but we'll need to test that. A separate stduser (which we have in production) that is unrelated to the web server should probably own most of the files instead.

The vulnerability we want to protect against here is a security flaw in the web server itself (which the entire world has access to), so restricting how much damage the web server can do on the file system is a best practice.

[rachejazz]

https://github.com/openmainframeproject/software-discovery-tool-deploy/blob/f0a18279df4e70ee92a3384e2fde190b0c872158/.github/workflows/cicd.yml#L20

This line is followed in our deployment. Surely there should be more ways to check which process is using sudo in our server. I do have a script written for my server that sends alert on slack if some user has used sudo on my server with the pid. Should we use something like that too?

Sudo-notifier script: https://github.com/rachejazz/DevSecOps-Automation-and-Monitoring/blob/main/sudo-notifer

[pleia2]

Now that the web server user should not require write access to the file system to do data file updates, we should do a thorough re-evaluation of ownership in our installation documentation, and probably have a specific sdt user set up to own these files instead.