|
Basically same answer, but slightly more elaborate:
First thing I think should be a question: is there anything you can do to reinforce server security regardless of what you're running? Yes: apply the GRSecurity patch or run SELinux. Both provide means to restrict process access to any files but GRSecurity and SELinux can't be used at the same time. Leaving other specs there and focussing on FIFO's GRSecurity guards against symlink and FIFO abuse in general while SELinux provides a security class for FIFO's to control access with.
The second thing would be to take the whole thing apart and see what minimal rights are necessary to run it. I take it what basically we're talking about is the "SIP Express Router" application (ser), helper apps (like serctl) and a front-end (serweb). serweb needs access to the FIFO to send commands to ser and receive output: the FIFO here serves as a way to rise above privilege problems (serweb or serctl would not be able to fetch data itself unless run as root). While not of direct concern here, it would be interesting to know in what way ser itself needs root account privileges and if it drops any once the service is started. Since ser here runs as root (and the FIFO resides in a publicly accessable directory) that side of the FIFO will have no problem reading or writing to it so we only need to find the rights for the serweb side.
Generally speaking PHP-based apps have a long history of problems ranging from cross-site scripting to input validation problems and continue to do so. Input validation errors here are an easy way to get the system to perform tasks you would not want it to. Unless there's a chance for gaining access to higher privileges these tasks run as the process owner the webserver runs as which sort of curbs damage (unless run as root).
Since the process on the other end of the FIFO runs as root, the only way to run PHP-based apps "safely" is (next to forcing developers to audit any weak input validation) to apply basic PHP security settings, run the code as unprivileged user (in your case "www-data") and not allow unauthorised access to serweb's pipe-writing commands. Next to this and basic server hardening there's additional measures to look into like running the webserver chrooted, using Hardened-PHP, running mod_security, using su-PHP (or say sudo) to allow access to commands to name a few. Running code as the process owner the webserver runs as you can chown the FIFO root.www-data and chmod it 0770. If anything breaks you need to enable full debug output and look at the logs before deciding to go back to making the FIFO FFA.
Going back to the FIFO directory we already mentioned it's publicly accessable, so it should have "noexec,nosuid,nodev" flags, except "nodev" will break FIFO usage, so skip that. This is not a "catch-all" measure but will thwart some abuse.
To recap:
- do make sure processes have no access beyond their boundaries (harden server),
- do run code as unprivileged user,
- do change mode and ownership of the FIFO,
...leaving only (in this limited scope) input validation as "main" weakness.
If anything of the above is blatantly wrong I gladly accept corrections.
|
