User írásjogának globális elvétele (linux)

Szerintem a biztonság ott kezdődik, hogy mezei user alapból nem írhat sehova. Tehát nem elvenni kell az írásjogát, hanem eleve ne legyen senkinek. Nem túl sok hely jöhet szóba, nézz utána, hogy lehet /tmp meg ilyesmi mappákat leszabályozni. Illetve PHP szinten is be lehet zárni, hogy a fájlrendszer érdekesebb részeit eleve ne is lássa. Ha jogot akarsz adni 1-1 mappára, akkor simán chmod/setfacl, esetleg használj csoportokat és lehet a júzert ki/betenni, efölött szerintem kár bonyolítani.

En a teljesben modositanek ACL-el. Ha ACL mar van az fs-en akkor jo, ha nincs akkor jo lenne.

Ha jól sejtem, ez amolyan kvázi-hosting környezet. Erre való tekintettel a következő megoldásokat tudom javasolni: (FIXME ha kihagytam valamit vagy helytelenül nyilatkoztam, régen nézegettem néhányat ezek közül.)

1. File-szintű védelem

A legegyszerűbb megoldás átlalában a legjobb. Ha tudod, akkor egyszerűen korlátozod, hogy az adott user mihez férhet hozzá. A probléma akkor kezdődik, ha azt akarod, hogy az FTP más jogosultságokkal rendelkezzen mint a PHP. Ilyen setupban rendszeres probléma az, hogy a PHP által írt fájlok FTP-ről nem törölhetőek, ha a kettő nem fut azonos userrel. Léteznek ugyan ACL-ek, de ezeket nem éppen egyszerű konfigurálni és sokszor előfordul, hogy egy ACL-ekről nem tudó PHP vagy FTP program előállít egy olyan fájlt, ami aztán kézi matatást igényel.

Side note: remélem, nem használsz FTP-t. Felejtsük már el ezt az ósdi, szar protokollt. Olyan szép SSH/SFTP szerverek vannak...

2. MPM-ITK + kernel-szintű védelem

Az MPM-ITK alapvetően arra készült, hogy minden user egyazon gépen belül fusson, így minden PHP folyamat és FTP user úgy viselkedik, mint egy mezei Linux/Unix user, és ennek megfelelően alakul a permission rendszere is. Az open_basedir használata mint biztonsági mechanizmus csak korlátozottan hasznos, ráadásul mellékhatásként kikapcsolja az opcache-t is. Éppen ezért érdemes lehet a Linux kernel felé fordulni és valamilyen access control megoldás (pl. RBAC) után nézni. Ezzel le tudod tiltani az, hogy a folyamat és gyerekei, vagy akár bizonyos userek bizonyos fájlokat el tudjanak érni. Ilyen megoldásokat találsz a SELinuxban, a grsecurityben, vagy az AppArmorban. Mivel vélhetőleg az összes vhostod egy jól elkülöníthető könyvtárban van, így elegendő az Apache jogosultságait arra a könyvtárra + néhány másikra korlátozni.

3. bind mount

Ha kisérletezős kedvedben vagy és nem sajnálod az erőforrást, azt is csinálhatod, hogy az írható és nem írható könyvtárakat külön mountolod ro/rw opcióval. Mondanom sem kell, hogy ez nem egy praktikus megoldás sok vhost esetén, egyrészt azért mert kézzel kell konfigurálgatni, másrészt mert a nagy számú mount érdekes helyeken belassíthat folyamatokat a gépen. Nem nagyon, de érdekes mellékhatásai vannak ha egy program nincs felkészülve rá.

4. LXC/docker

Azt is megteheted, hogy minden weboldalnak adsz egy külön Docker vagy LXC containert. Ez különösen akkor működik jól, ha az adott szoftver tulajdonosa nem egy fakapás PHP táker és képes megmondani, hogy hova szeretne production környezetben írni és hova nem. Mindkét technológia ad megoldást arra, hogy az írható könyvtárakat külön mountold, és ennyiben hasonlít a bind mountos megoldásra.

A hátránya természetesen az, hogy az ITK-t el kell felejteni, leginkább az nginx+PHP-FPM irányba lenne érdemes elmozdulni. Itt a Docker előnye az is lehet, hogy a szoftverfrissítés megoldható egy egyszerű container frissítéssel a fejlesztő részéről, miközben az adatkönyvtárak megmaradnak, valamint az sem elhanyagolható tény, hogy tudsz különböző PHP verziókat futtatni egy és ugyanazon gépen.

Összegzés

Sok szép és jó technológia létezik a PHP bekorlátozására, de sajnos az a nagy igazság, hogy ha a "fejlesztő" FTP-n akarja hegeszteni a fájljait, akkor ezzel az egésszel nem lesz sok sikered. Ennek az oka baromi egyszerű: egy Wordpress plugin, vagy egy PHP Hegesztő István által előállított program egyik napról a másikra megváltozhat úgy, hogy egyszer csak írni akar valahova ahova előzőleg nem akart, és ezért az oldal tulajdonosa sírni fog.

Éppen ezért, ha nincs a fejlesztő részéről együttműködés, érdemes inkább elmenni abba az irányba, hogy írjon ahova akar, max visszaállítjuk mentésből, és emellett jól bekorlátozni hogy mit tud csinálni a saját könyvtárába írás kivételével. (chroot, container, tűzfal, stb.)

Bónusz szegmens

Ha mindenféle korlátozásokat implementálsz, figyelj arra, hogy a TMP, TMPDIR vagy TEMP környezeti változók által említett PHP könyvtárba a PHP tudjon írni, különben érdekes és izgalmas debug sessionökben lesz részed. Ugyanez igaz a upload temp könyvtárra és a session könyvtárra is. (Az utóbbit illik takarítani is, ami Debian rendszereken defaultbol ki van kapcsolva mert cronból oldják meg.) Ha open_basedir-t használsz, ezen könyvtárak mindegyike legyen a basedir-en belül, különben szintén izgalmas problémákba fogsz belefutni random PHP scriptekkel.

Ezen felül ha még nem tetted, javaslom a disable_functions-ba betenni a következő függvényeket:

exec,passthru,proc_open,proc_nice,shell_exec,system,popen,pcntl_exec,posix_kill,posix_setsid,pcntl_exec,pcntl_fork,dl

--
Pásztor János
Sole Proprietor @ Opsbears | Refactor Zone

chmod o-x /
nem rekurzívan, nem mindenhol matatva. Egyedül a a rootdir-en. Bár nyilván rá fogsz jönni, hogy nem ezt szeretnéd, mert ez az igényeltnél sokkal több mindent fog korlátozni :-)

=====
tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

"Ugyanez a user másolhatja fel ftp-vel a fájlokat is a tárterületére."
Vedd külön a két usert, máris nem lesz joga az oldalt futtató usernek a tárterülethez.
Ahova kell még mindig adhatsz külön jogot.