23 Feb
2016
23 Feb
'16
4:21 p.m.
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
23 Feb
23 Feb
4:31 p.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
To je AFAIK jediná jednoduchá možnost.
4:39 p.m.
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(a)keroub.cz>cz>:
Jediné řešení, které mě napadlo je, že bych musel pro
daný projekt
--
S přáním pěkného dne,
Martin Mikšaník
gsm: +420 602 623 934
icq: 311047283
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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
4:57 p.m.
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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
5:14 p.m.
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(a)keroub.cz> wrote:
On 02/23/2016 05:39 PM, Martin Miksanik wrote:
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(a)lists.vpsfree.cz
> http://lists.vpsfree.cz/listinfo/community-list
>
_______________________________________________
Community-list mailing list
Community-list(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
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 :)
4:51 p.m.
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(a)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(a)lists.vpsfree.cz
http://lists.vpsfree.cz/listinfo/community-list
2998
days inactive
2998
days old
community-list@lists.vpsfree.cz
5 comments
4 participants
participants (4)
-
Ghormoon -
Jan B. Kolář -
Jirka Bourek -
Martin Miksanik