PHP safemode 대안

Question

안전 모드는 5.3.0으로 폐지되었습니다. 나는 실제로 그것을 요구하지 않았고 오히려 과거에 허가 오류 등으로 인해 여러 번 문제가 있음을 발견했습니다.

그러나 지금 나는 안전 모드가 훌륭했을 것이라고 생각합니다.

모듈을 통해 확장 가능한 웹 응용 프로그램을 만들었습니다. 나는 시스템을 직접 호스팅하고 지불 고객이 시스템의 다양한 부분에 연결되는 모듈을 구현하고 작성함으로써 소프트웨어를 확장 할 수 있도록 할 계획이다.

내 관심사는 그렇게함으로써, 업로드 한 코드가 기초/프레임 워크를 스캔하지 못하게하는 방법이 없었기 때문에 필자는 설계와 테스트를 수년간 보냈다. 독점적 인 코드를 유지하는 것은 나에게 큰 관심사입니다.

1. 제 3 자 모듈에서 불법적 인 메소드가 호출되지 않도록 모듈 분석 도구를 작성합니다.

2. I php.ini 수준에서는 유해한 기능을 사용하지 못하지만 fopen()을 포함하면 ilk이므로 프레임 워크가 자체 include() 작업 등을 호출 할 수 없습니다.

3. 마지막으로 같은 ID, 그룹을 공유하지 않는 파일을 읽을 수의 사용자 모듈을 제한하는 슬프게도되지 않는 안전 모드 등

그런 일에 권장되는 방법은 무엇입니까 ? 내 프레임 워크의 컨텍스트에서 실행되기 전에 각 모듈을 수동으로 검토하거나 자동으로 분석하지 않습니까?

Answer 1

safe_mode이 제거되고있는 것이 좋습니다. 그 secuirty의 거짓 감각, 그리고 많은 그것을 무시하는 방법이있다.

더 나은 방법은 신청서를 구속 된 사용자로 실행하는 것입니다 (suphp). 이것은 운영 체제의 보안을 사용하여 응용 프로그램을 보호합니다. exec() 및 system()을 금지하는 대신 쉘에 액세스 할 수없는 계정으로 PHP 코드를 실행합니다. fopen()을 금지하는 대신 해당 사용자가 소유 한 모든 항목에서 쓰기 권한을 제거합니다. chmod 500 -R /. 또는 한 단계 더 나아가서 chroot 내에서 애플리케이션을 실행하십시오.

Answer 2

safemode 대신 chroot, mod_ruid 및 php-fpm의 사용자 권한 및 php의 opendir 제한과 함께 php-fpm을 사용할 수 있습니다. 이렇게하면 안전 모드를 훨씬 더 엄격하게 만들 수 있습니다.

개인적으로 chroot를 사용하여 php-fpm을 권장하고 exec 및 system과 같은 시스템 기능을 비활성화하십시오. 어쨌든 그들은 악합니다.

Answer 3

나는 안전 모드를 무시 /etc/php/7.0/fpm/php.ini에 open_basedir로 를 사용하는 권장되는 방법은 당신이 젖은과 죽음에 위반자를 고문 할 수있는 라이선스 계약을 사용하는 것입니다