SElinux and php
 

Long story made short, because of SElinux I couldn't get a php file to write a file in safe_mode with fopen..

So, had to chown the httpdocs/ folder to apache:apache.

Now, people keep telling me this is bad, and I'm sure it is, but can anyone tell me why? :/ And any way to getting around the SElinux/safe_mode thing with fopen?

Thanks..

What causes the most widespread security issue with PHP, or phrased differently, in what ways can fopen() be abused? With what checks does safe_mode try to mitigate risks? With what directives can you relax safe_mode? Does this then suggest that if you get fopen() errors and have enabled PHPs safe_mode and SELinux, that you have to look at SElinux or PHPs safe_mode first?

Thanks for moving this thread btw .. sorry about the duplicate.

As far as I can understand, there's no way around SElinux + php safe_mode (And I can't disable safe mode due to security issues with other parts of my application). There are no inherent risks with fopen() but I'm wondering how making apache the folder owner will affect the overall security of my site.

AFAIK, apache can only read things on it's own server so to be able to run malicious code a user would first have to plant a file in the wwwroot dir and THEN run it right? Because if that's the case, then so be it.. if you can get access to my server then all hope is lost anyway ;)

IMHO the "right" path for looking at your problem is first fopen() vs PHP safe_mode. If you understand how and what safe_mode restrictions you can or can not relax, *then* to look at SELinux "apache domain" configuration.


So you're saying coding flaws like remote file inclusion has never been a problem? Neat!
Now pick up the Go To Jail card and think it over for the next ten rounds.


Unless you're using any form of suexec, Apache only looks at filesystem permissions (aka DAC rights) to see what or where it can read, write or execute. SElinux works *on top of* DAC rights and will keep Apache (or abuse) from permeating the system (if sufficiently configured). That's why I say you should first look at PHPs safe_mode.

I realize that you guys are jaded from questions, but I don't see why you feel the need to patronize me when I ask an honest question.

I'm no expert by any means, I thought the OP made that abundantly clear.

"Remote File Inclusion" is something that really doesn't apply here either. All the php script is doing is writing a XML file. The name is specifically named in the php file, no variable stuff. It's not really "asking" for anything. Just a call to write the file.

That's all.

Was just wondering if apache owning wwwroot can lead to anything bad happening, remotely.

I did not and do not intend to patronize you, so please don't interprete it as that.

"File permissions" aka DAC (Discretionary Access Rights) rely on the principe of least-privilege aka separation of rights. User should have only access to what they need and nothing else, and as far as Apache is concerned for it owning it's own $DOCROOT, all the docs are clear on that: not the user Apache runs as but "root", "nobody", "web" or "www-data" or any other nologin-shell inert user account that's not used by other processes. Using another user account as owner ensures that the user Apache runs has no write access outside it's boundaries and can not taint, modify files. Where execute and write rights are needed (in case you don't run suPHP) this needs to be confined to only specific parts of the $DOCROOT tree and with as much care for DAC rights as possible.

AFAIK the common method to allow writes as user "irdeveloper" is to have a group (called say "www") and have this user and the user Apache runs as in that group, then for PHP in safe_mode in addition the CGI needs to have added set-group-id rights and then have checks relaxed using safe_mode_gid. Of course not being an expert I may be totally off my rocker and as such will accept any corrections.

If none of the above is the case, or if you applied everything you could and you are sure it is not a PHP safe_mode but a SELinux issue, and you have httpd_enable_cgi (or equiv) enabled, then please post the related AVC messages.