On 08/21/2018 05:45 PM, Warren Young wrote: > >> I could be convinced otherwise if I could see where running the php as the app users, would make more sense. > That depends on whether the boundary between user php and this unknown “appuser” is bidirectional or not. > > If there are things owned by user “php” that “appuser” should not see, then continuing to run the web app as two separate users makes sense. > > If “appuser” can be said to own everything in the web app, and the only reason you’re converting user php privileges to “appuser” privileges is so you don’t have to give user php access to everything in the web app, then I’d say my prior suggestion holds. > > Now that I know you’re using PHP, I can recommend something like PHP-FPM: > > https://php-fpm.org/ > > That’s the old external project. It’s now part of the PHP core: > > https://secure.php.net/manual/en/install.fpm.php > > You’ll have to use the old version with C5, though, as that happened after C5 was released. > > FPM isn’t the only way to go, just one idea, which happens to be well-supported within the PHP community. > > Regardless of the exact method, this lets you run your PHP code as a non-php user, letting Apache proxy to it using mod_fcgi. Now you’ve got strong separation between things Apache is allowed to read and things it must talk down through PHP to get access to. > >> It could be that giving sudo sys_ptrace access could increase the risk to the security of the system > Once you give a process ptrace ability, it’s pretty much game over when it comes to security. The scope of what one process can do to another via ptrace(2) is HUUUUGE. I’d very much resist placating SELinux in this way. > > SELinux might in fact be warning you about a real attack here, which would explain why it’s intermittent. > _______________________________________________ Thank you, this information was helpful. I will solve the problem without allowing ptrace capability. Nataraj