add security.level for php-fpm #65935

[krakjoe]

https://bugs.php.net/bug.php?id=65935

It went something like this:

Someone asked for suexec like functionality, a gid/uid check, which I implemented.
Some other people said can we do more.
Remi pointed out that suexec is much more

http://httpd.apache.org/docs/2.2/suexec.html

suexec is loads, and restrictive, all the time.

So for php-fpm only I implemented a security level to give a bit of power to the user in configuring their security.

Lastly ... SECURE ALL THE THINGS !!!

[derickr]

What's with the extra new lines?

[derickr]

And there is more broken whitespace/indentation.

[remicollet]

Do you really think that script uid matching proccess uid increase security ?

I mostly think the opposite.
If the user running the process is also the owner of the script, it will have "write" access to it (so making exploit possible).

I usually think that the process "must not" own the script and have only "read" right.

[remicollet]

I think another check could make sense:

"webserver" user can only excute script from a "webauthor" (with webserver != webauthor), thus is any file is added by some exploit, it won't be executable.

P.S. which I think is mostly what suExec do.

[krakjoe]

http://httpd.apache.org/docs/2.2/suexec.html

1. ...
2. ...
3. Is this valid user allowed to run the wrapper?
   Is this user the user allowed to run this wrapper? Only one user (the Apache user) is allowed to execute this program.

Seems quite similar to suexec to me ??

I'm up for implementing varied modes of security while we are at it all the same ...

[krakjoe]

This has been totally done over ...

; Set the security level for FPM
; Security level is on the scale of 0-8, where 0 means no security checks are performed
; Setting the number to, for example 5, means level 5 and below security requirements are 
; enforced for each request
;
; Default Value: 0
; Values:
;   1: do not allow any script to execute as root user
;   2: do not allow any script to execute as root group
;   3: do not allow access to paths with backreferences ".."
;   4: do not allow access to anything not a regular file
;   5: do not allow access to executable files
;   6: do not allow access to paths that are readable or writable by any other group
;   7: do not allow access to paths that are writable by the current user or group
;   8: do not allow access to paths where the group and user do not match the current group and user *exactly*
;
; At level 8, only files owned by the current user and group, with permissions 400 may be executed.
security.level = 8

Delicious now, right ??

[remicollet]

From http://httpd.apache.org/docs/2.2/suexec.html

3. Is this valid user allowed to run the wrapper? Is this user the user allowed to run this wrapper? Only one user (the Apache user) is allowed to execute this program.

This means that the wrapper can only be called by apache. The wrapper, not the script.
But:

8. Is the target userid ABOVE the minimum ID number?

This means the script will run under an unprivileged account which is obviously not apache. But suExec is something special.

So definitively, having process uid = script owner doesn't make sense, from security POV.

[krakjoe]

Coming back to this later ...