ettoredn / selix Goto Github PK

The target context == current context condition is only checked in set_context function called by the already created one-time thread. Because the goal of thread creation is transitioning to a new context, the target ctx == current ctx condition must be also checked prior to thread creation in order to avoid unnecessary threads and improve performance.

At the moment, if target security context doesn't exist an exception is raised with zend_error showing:

Fatal error: setcon() failed in Unknown on line 0

which is cryptic.
In order to give a more clear error depending on the situation (target context doesn't exist or unknown setcon() error), a check for target context existence must be added.

Output produced by selix_debug should be controlled by a world-writalbe (PHP_INI_ALL) ini setting.

If neither SELINUX_DOMAIN and SELINUX_RANGE environment variables are specified, php returns error and doesn't execute scripts.

If no compilation context is defined it is expected to execute zend_compile in the same context as zend_execute, thus in the execution security context.

Scripts using curl_exec() cause segmentation fault if CURLOPT_TIMEOUT elapses.
A script to replicate the bug has been created: https://github.com/ettoredn/sephp-sandbox/blob/master/webroot/bug_9.php

After a request returns a compilation error FPM process stucks in virtual host's security context without return in the default one (i.e. php_t).

Request raises a compilation error:
[*] Compiling /home/sephp/sephp-sandbox/webroot/selinux_test.php
[SC] Current context: system_u:system_r:php_t:s0
[SC] New context: system_u:system_r:sephp_php_t:s0
Parse error: syntax error, unexpected '}', expecting ',' or ';' in /home/sephp/sephp-sandbox/webroot/selinux_test.php on line 69

Next request:
[*] Compiling /home/sephp/sephp-sandbox/webroot/selinux_test.php
[SC] Current context: system_u:system_r:sephp_php_t:s0
[SC] No context chages made

Avoid the hardcoding of PARAM_DOMAIN_NAME and PARAM_RANGE_NAME but, instead, get their values from INI directives.

E.g.: zend_hash_find(PG(http_globals)[TRACK_VARS_GET]->value.ht, "XDEBUG", sizeof("XDEBUG"), (void **) &dummy)

With selix enabled, $_POST array doesn't get populated.

Development has relied on FPM implementation. Further compatibility checks are needed for other SAPI implementations, most notably apache2handler and cli.

When the key gets deleted ( zend_hash_del() ) the next element becomes the current so there's no need to zend_hash_move_forward_ex(). The problem is that by being in the inner loop it isn't possible (in a clean way) continue the outer loop, thus the need to move backwards before remove the key in the inner loop.
A clean solution could be swith loops (inner becomes outer) in order to have the hash walking one "continuable".

Same behavoir of issue #6 but triggered by an abrnormal termination of zend_execute() ( e.g. script executes a die() ).