Hi,

I've got a situation where a php application (serweb) needs read/write access to a pipe (/tmp/openser_fifo) on a debian testing server with apache2. The serweb php application works if I chmod 777 /tmp/openser_fifo.

I may be wrong but the idea of opening the pipe to all seems like a disaster waiting to happen.

What I need is a set of groups or permissions that allows only the php application (serweb) access to /tmp/openser_fifo.
Can someone please give me some pointers on how they might handle this?


I tried the following:

Running openser under user www-data doesn't seem wise.
I tried making a new group with www-data and openser groups in it, then assigned that group to /tmp/openser_fifo but it only works as 777 again.

For right now, openser currently runs as root. Root owns the php files for serweb. Both need to be run at lower privileges. But first I need some feedback on how to protect /tmp/openser_fifo

I would create a new user that would belong to group www-data (assuming that is the group ID apache is running) and run your server application with that user. Then chmod the pipe with 770.

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.

Big thanks for both replies. It works and I think it is good for right now and *much* better than where I was going.

FYI: I'm running openser ( a fork of service express router) as a new user in the group www-data and it works great. The pipe still comes up as belonging to root, but I change permissions and everything works great.