There should be a new test for ownership of files and directories

The exceptions for ownership should be the same as for the writing permissions. There could also be more folders as "files" and "tmp" like special cache folder of the boost module.

We should avoid that a successful attacker can place additional code on the file system. With drupalgeddon we had mass exploits of the menupath with placing additional code in the file system via php to turn drupal systems into SPAM-machines. Maybe this exploits can be extended with additional chmod commands.

Since today I already have an idea how to open the write access if there is a problem like on drupalgeddon but I didn't want to share this information on this public forum. If the security team is interested we can discuss this in the closed security forum. But I believe they can also imagine how to bypass this small barrier of write access when the webserver user is the owner of an directory but currently it's write protected.
With my work on my new chmod-module I found a solution based on a fast exec-find-solution with searching all files and folders where the webserver is the owner. This is the basement of a following chmod-command inside a single exec-command. In the same way I can write a test for this module but maybe there are problems with the compatibility on php setups where the usage of exec is limited. On the other side I see some possibilities for a better performance with the current "Safe file system permissions"-test if we use the find command of the operating systems if exec and this command is available maybe as an alternative testing method.

The main problem is now addressed in this issue: #3454866: file check is problematic "green" when not test with chmod

The related issue is more important because it directly checks the the ability to change permissions not only the potential to do so. The file owner check should maybe be separate because there could be server strategies to avoid changes of permissions like chattr and the ownership of a file cannot be used for changing permissions. And if this is the case it would be helpful to deactivate this check.
(Edit: corrected logic of first sentence)

Because "SecurityReviewData->findWritableFiles" is already checking the fileowner I think it would be a good idea to move this code to another function which could return two values: writable and possibly writable because of ownership. For backward compatiblity we can keep the old function as wrapper.

I hope in winter I find some time to push the file permission issues forward if no one else step in.

@smustgrave Because there could be mixed ownership situation we need a logic that detects that the webserver is the owner code files or maybe everything which is not intended to be writeable like the public and private files folder etc.

But the idea of a configuration or better setting variable is good. If a test runs via webserver we ca get this information directly and maybe give a warning if setting is not present or different.