Ich habe ein PHP-Skript, das versucht, mithilfe von exec (oder shell_exec) eine Binärdatei auf dem System auszuführen. Die Ausführung schlägt mit dem Rückgabecode 127 fehl.
Der Rückgabecode 127 bedeutet normalerweise, dass der Befehl nicht gefunden wurde. Daher habe ich darauf geachtet, den absoluten Pfad zur Binärdatei zu verwenden. Keine Änderung.
Apache ist für die Ausführung in einem Chroot unter Verwendung des ChrootDir von Apache konfiguriert.
Ich habe darauf geachtet, die Binärdatei in den richtigen Pfad im Chroot sowie in /bin/sh und alle für beide erforderlichen verknüpften Bibliotheken zu kopieren.
Apache (und damit auch PHP) laufen als www-data. Ich habe bestätigt, dass www-data Lese- und Ausführungsberechtigung für die Binärdateien (einschließlich /bin/sh) und alle übergeordneten Ordner hat. Um zu bestätigen, dass es sich nicht um ein Problem mit den Dateiberechtigungen handelt, habe ich den Befehl mit /bin/sh -c unter Verwendung von sudo ausgeführt:
sudo -u www-data /chrootdir/bin/sh -c /chrootdir/path/to/binary
Und das funktioniert problemlos.
Mit strace erhalte ich Folgendes:
execve("/bin/sh", ["sh", "-c", "/path/to/binary"], 0x7ffe436b3618 /* 11 vars */) = -1 EACCES (Permission denied)
Nur um zu bestätigen, dass das Berechtigungsproblem die sh-Binärdatei betrifft (und die im Chrootdir), habe ich versucht, /chrootdir/bin/sh in etwas anderes umzubenennen, habe Strace erneut ausgeführt und jetzt wurde eine Fehlermeldung angezeigt, dass die Datei nicht gefunden wurde.
Ich weiß jetzt also, dass das Problem beim Zugriff auf /chrootdir/bin/sh liegt, wenn es über PHP über Apache ausgeführt wird, es sich aber nicht um eine Berechtigung des WWW-Data-Benutzers handelt.
Ich bin nicht sicher, was ich als nächstes versuchen soll.
Dies läuft auf Debian 10, Apache 2.4.38 und PHP 7.3.11.
Ich habe open_basedir gelöscht und auch disable_functions gelöscht.
Ich habe bestätigt, dass Apache nicht durch Apparmor eingeschränkt ist, habe es aber trotzdem deaktiviert.
Wenn ich schließlich das Apache-Chroot deaktiviere, funktioniert dies.
Meine Frage ist daher: Gibt es irgendwo eine andere Einschränkung, die Apache daran hindern könnte, dies zu tun?
Antwort1
Dank des obigen Kommentars von @Michael Hampton habe ich versucht, mit dem Befehl chroot einfach als Root nach /chrootdir zu wechseln. Das war nicht möglich. Ich erhielt Folgendes:
chroot: failed to run command ‘/bin/bash’: Permission denied
Ich habe auch versucht, wie von ihm vorgeschlagen /bin/sh -c /path/to/binary auszuführen (aber als Root, da www-data den Befehl chroot nicht verwenden kann). Und das hat denselben Fehler „Berechtigung verweigert“ ergeben.
Die Tatsache, dass es ordnungsgemäß ausgeführt wurde, als ich einfach „sudo -u www-data /bin/sh ...“ verwendete, aber nicht mit dem Chroot-Befehl, bedeutete, dass das Problem bei den verknüpften Bibliotheken liegen musste.
Bei weiterer Untersuchung stellte sich heraus, dass die Bibliothek /chrootdir/lib64/ld-linux-x86-64.so.2 nicht ausführbar war. Das Problem wurde behoben, indem die Bibliothek ausführbar gemacht wurde.