Zdravím všechny,
chtěl jsem Vás poprosit o radu/názor ohledně nastavení user/group u php-fpm z hlediska bezpečnosti. Používám php-fpm v kombinaci s nginxem a největší obavu mám z napadení php aplikace. Chtěl jsem proto nastavit souborová práva takovým způsobem, aby se v případě napadaní aplikace minimalizovala možnost jejího zneužití k šíření malware.
Samozřejmě jsem přečetl různé návody na netu a pro každou php aplikaci si vytvářím vlastního uživatele, pod kterým běží php-fpm pool (user "project", group "project"). Uživatel www-data (nginx) pak je součástí skupiny "project", aby měl přístup k souborům. Na všechny složky jsem nastavil právo jen pro čtení (440), pouze u "tmp" složek, kde si php aplikace vytváří dočasné soubory, jsem nastavil právo 640. V nginxu jsem pak nastavil, že se ze složky "tmp" nesmí nic servírovat ven (php aplikace tam ukládá jen soubory pro svoji vnitřní potřebu, není potřeba k nim přistupovat zvenčí).
Celé mi to přišlo jako ohromné řešení, dokud mi nedošlo, že owner souborů může provést chmod. Tzn. běžící php-fpm pool si může na složkách či souborech nastavit právo pro zápis, "kompromitovat" soubory a servírovat je návštěvníkům.
Udělal jsem tedy co nejstriktnější omezení u ngnixu - tzn. přesně jsem vyjmenoval z jakých složek se můžou servírovat jaké soubory (např. z "/assets" pouze .js, .css., .jpg, z "/" jen index.php, z "/tmp" složky vůbec nic). Pořád mi ale vrtá hlavou nastavení přístupu k souborům.
Jediné řešení, které mě napadlo je, že bych musel pro daný projekt vytvořit uživatele dva a jednu skupinu. Php-fpm pool by pak běžel pod "project-pool":"project", všechny soubory by ale vlastnil "project":"project". Skupina by měla přístup jen pro čtení a php-fpm pool by to nemohl změnit. Skupina by měla práva zápisu jen do složky "/tmp", aby si mohla aplikace vytvářet dočasné soubory.
Jenže jsem na takové nastavení práv nikde nenarazil a tak nevím, jestli jsem to moc "nepřekombinoval" :-D
Předem díky za reakce,
Honza
Jediné řešení, které mě napadlo je, že bych musel pro daný projekt vytvořit uživatele dva a jednu skupinu. Php-fpm pool by pak běžel pod "project-pool":"project", všechny soubory by ale vlastnil "project":"project". Skupina by měla přístup jen pro čtení a php-fpm pool by to nemohl změnit. Skupina by měla práva zápisu jen do složky "/tmp", aby si mohla aplikace vytvářet dočasné soubory.
Jenže jsem na takové nastavení práv nikde nenarazil a tak nevím, jestli jsem to moc "nepřekombinoval" :-D
To je AFAIK jediná jednoduchá možnost.
Podle me tohle celkem dobre resi BaseDir v php. Jinak ja treba bezim s userama pres nginx + uwsgi(php, python, ruby), kde si muzes hrat i s vlastnim chrootem, usery tahat z DB atd. Muzes to taky cele zavrit do selinuxu, kde si prava nastavis.
Jinak -> kdyz nginx miri sam pouze na staticke soubory - nema kam uhnout Nginx keca s php-fpm ktere serviruje jen php soubory (omezeni pres chroot, basedir). Pokud si nekdo sam chmodne soubory, je to jeho pruser (pripadne aplikace), ale i tak by se k nim nemel nikdo dostat. Muzes klidne funkci chmod v php zakazat :)
2016-02-23 17:31 GMT+01:00 Jirka Bourek vpsfree-list@keroub.cz:
Jediné řešení, které mě napadlo je, že bych musel pro daný projekt
vytvořit uživatele dva a jednu skupinu. Php-fpm pool by pak běžel pod "project-pool":"project", všechny soubory by ale vlastnil "project":"project". Skupina by měla přístup jen pro čtení a php-fpm pool by to nemohl změnit. Skupina by měla práva zápisu jen do složky "/tmp", aby si mohla aplikace vytvářet dočasné soubory.
Jenže jsem na takové nastavení práv nikde nenarazil a tak nevím, jestli jsem to moc "nepřekombinoval" :-D
To je AFAIK jediná jednoduchá možnost.
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
On 02/23/2016 05:39 PM, Martin Miksanik wrote:
Podle me tohle celkem dobre resi BaseDir v php.
Basedir je AFAIK něco, co vývojáři PHP považují za broken by design. Navíc když je to zapnuté, některé věci nefungují (tím neříkám, že se to nemá používat, jenom že to není zázračné řešení.)
Navíc tazatel - jestli jsem dobře pochopil - řeší možnost, že code execution chyba v jeho aplikaci umožní někomu udělat chmod na kód/data webu a donahrát tam vlastní soubory. Proti tomu basedir neochrání.
Jinak ja treba bezim s userama pres nginx + uwsgi(php, python, ruby), kde si muzes hrat i s vlastnim chrootem, usery tahat z DB atd. Muzes to taky cele zavrit do selinuxu, kde si prava nastavis.
Jinak -> kdyz nginx miri sam pouze na staticke soubory - nema kam uhnout Nginx keca s php-fpm ktere serviruje jen php soubory (omezeni pres chroot, basedir). Pokud si nekdo sam chmodne soubory, je to jeho pruser (pripadne aplikace), ale i tak by se k nim nemel nikdo dostat.
Tolik teorie. Od praxe se liší především v praxi, zejména když jde o Wordpress a podobné. ;-) A kdo za to pak může už je jedno, stejně se to musí řešit.
Muzes klidne funkci chmod v php zakazat :)
S tímhle přístupem (věřím, že zakázané funkce nejde znovu povolit) by to php mohl spouštět pod www-data ;-)
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Imho blacklistovat funkci je spatny pristup. Mas veci jako exec a buhvi co jeste - vzdycky muzes na neco zapomenout. Blacklist jako jedina seciruty featura nestaci, musis tam mit nejakou obecnou. On Feb 23, 2016 5:59 PM, "Jirka Bourek" vpsfree-list@keroub.cz wrote:
On 02/23/2016 05:39 PM, Martin Miksanik wrote:
Podle me tohle celkem dobre resi BaseDir v php.
Basedir je AFAIK něco, co vývojáři PHP považují za broken by design. Navíc když je to zapnuté, některé věci nefungují (tím neříkám, že se to nemá používat, jenom že to není zázračné řešení.)
Navíc tazatel - jestli jsem dobře pochopil - řeší možnost, že code execution chyba v jeho aplikaci umožní někomu udělat chmod na kód/data webu a donahrát tam vlastní soubory. Proti tomu basedir neochrání.
Jinak ja treba bezim s userama pres nginx + uwsgi(php, python, ruby), kde
si muzes hrat i s vlastnim chrootem, usery tahat z DB atd. Muzes to taky cele zavrit do selinuxu, kde si prava nastavis.
Jinak -> kdyz nginx miri sam pouze na staticke soubory - nema kam uhnout Nginx keca s php-fpm ktere serviruje jen php soubory (omezeni pres chroot, basedir). Pokud si nekdo sam chmodne soubory, je to jeho pruser (pripadne aplikace), ale i tak by se k nim nemel nikdo dostat.
Tolik teorie. Od praxe se liší především v praxi, zejména když jde o Wordpress a podobné. ;-) A kdo za to pak může už je jedno, stejně se to musí řešit.
Muzes klidne funkci chmod v php zakazat :)
S tímhle přístupem (věřím, že zakázané funkce nejde znovu povolit) by to php mohl spouštět pod www-data ;-)
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
Hoj,
Kdyz budes resit oddeleni statickych dat, pohlidej si taky, jesti to o nemuze nakej kod naserviroat z databaze :) Ja osobne a jen jednoho usera per sluzba, podobne jak pises, ale to te chrani proti napadeni ostatnich sluzeb, ne proti napadeni vlastnich souboru. Pokud chces chranit zdrojaky, nezbyde ti nez mit jineho ownera a mit pravo jen na cteni. Obecne bys do slozek co se servujou apachem/fpm-poolem ven nemel psat, jediny vyjimky budou nejaky slozky na uploady, pokud to aplikace vyzaduje. Tam si zajisti, ze se ti zadny php nespusti. Pokud ses hodne paranoidni, muzes to rezat nejakejma namespacama. Ale to u se dostavamme na uroven kontajner per sluzba (coz ja treba v budoucnu asi budu delat ... jen este nebyl casoprostor). Gh. On Feb 23, 2016 5:22 PM, "Jan B. Kolář" janbivoj.kolar@zazen-nudu.cz wrote:
Zdravím všechny,
chtěl jsem Vás poprosit o radu/názor ohledně nastavení user/group u php-fpm z hlediska bezpečnosti. Používám php-fpm v kombinaci s nginxem a největší obavu mám z napadení php aplikace. Chtěl jsem proto nastavit souborová práva takovým způsobem, aby se v případě napadaní aplikace minimalizovala možnost jejího zneužití k šíření malware.
Samozřejmě jsem přečetl různé návody na netu a pro každou php aplikaci si vytvářím vlastního uživatele, pod kterým běží php-fpm pool (user "project", group "project"). Uživatel www-data (nginx) pak je součástí skupiny "project", aby měl přístup k souborům. Na všechny složky jsem nastavil právo jen pro čtení (440), pouze u "tmp" složek, kde si php aplikace vytváří dočasné soubory, jsem nastavil právo 640. V nginxu jsem pak nastavil, že se ze složky "tmp" nesmí nic servírovat ven (php aplikace tam ukládá jen soubory pro svoji vnitřní potřebu, není potřeba k nim přistupovat zvenčí).
Celé mi to přišlo jako ohromné řešení, dokud mi nedošlo, že owner souborů může provést chmod. Tzn. běžící php-fpm pool si může na složkách či souborech nastavit právo pro zápis, "kompromitovat" soubory a servírovat je návštěvníkům.
Udělal jsem tedy co nejstriktnější omezení u ngnixu - tzn. přesně jsem vyjmenoval z jakých složek se můžou servírovat jaké soubory (např. z "/assets" pouze .js, .css., .jpg, z "/" jen index.php, z "/tmp" složky vůbec nic). Pořád mi ale vrtá hlavou nastavení přístupu k souborům.
Jediné řešení, které mě napadlo je, že bych musel pro daný projekt vytvořit uživatele dva a jednu skupinu. Php-fpm pool by pak běžel pod "project-pool":"project", všechny soubory by ale vlastnil "project":"project". Skupina by měla přístup jen pro čtení a php-fpm pool by to nemohl změnit. Skupina by měla práva zápisu jen do složky "/tmp", aby si mohla aplikace vytvářet dočasné soubory.
Jenže jsem na takové nastavení práv nikde nenarazil a tak nevím, jestli jsem to moc "nepřekombinoval" :-D
Předem díky za reakce,
Honza _______________________________________________ Community-list mailing list Community-list@lists.vpsfree.cz http://lists.vpsfree.cz/listinfo/community-list
community-list@lists.vpsfree.cz
-
Ghormoon -
Jan B. Kolář -
Jirka Bourek -
Martin Miksanik