I've written a A linux systemunix wide C++ program /usr/bin/PROG_X that utilizes a configuration file /etc/PROG_X.conf and log file /var/PROG_X.log.

Now I have to refer to this as program, after strong authentication, on the internet using apache web server and php. Calling this program may involve altering configuration files and can change, obviously, log files.

I'm thinking about keeping SELinux enabled.

My Querstion is: What user/group and what file permissions ought to be looking for the binary file, configuration files and log files for proper and secure operation?

Which are more locked-lower approach (presuming the log and config are sensitive):

Apache runs as user 'www', 'progx' user and group is available for that sole reason for running /usr/bin/PROG_X.

/etc/PROG_X.conf is possessed by root:progx, and it has permissions 640
/var/PROG_X.log is possessed by root:progx, and it has permissions 660
/usr/bin/PROG_X is possessed by progx:progx, and it has permissions 500
/etc/sudoers enables www to operate only /usr/bin/PROG_X as progx.

Thus, only root and progx can easily see the config or read/write the log file, and just root can customize the config. Only progx can run this program, but apache can particularly launch your program as progx via sudo.

[Edit: skipped the part nevertheless this program might need to change its config file... therefore the permissions could be 660 rather]

Well, I'm not sure about SELinux, but there several "traditional" solutions spring to mind:

First, chown root /usr/bin/PROG_X after which set the setuid bit with chmod +s /usr/bin/PROG_X. The setuid bit causes this program not to run because the current user but as who owns the file (for the reason that situation, root). What this means is you should really make certain your program is really as secure as you possibly can. So use carefully.

An alternative choice to setuid may be to include a suitable entry in /etc/sudoers for that program and refer to it as via sudo. However it has got the same security implications because the program will run as root, but a minimum of you may be more fine-grained using the access (e.g. you can only permit the "www" user to operate this program as root).

Another solution may be to chown root:wwwrun all_of_the_files_that_PROG_X_need_to_modify. But that will only work knowing which files as well as in the event that group of files does not change.