Directive 'safe_mode' is deprecated in PHP 5.3

Internet: PHP, CGI, stb.

?? Az igaz hogy kellemetlen volt hogy kényszerítette ezt a sajátos fájlrendszer hozzáférés kontrollt. Hogy egybe lehetett csak bekapcsolni az egészet, és a funkciókat nem lehetett külön-külön kapcsolgatni, lett volna még mit finomítani rajta. De ezzel sok olyan dolog elveszik ami elég alapvető. Hogy fogom korlátozni a php-nak a futtatást, és a memória használatot, amelyek csak safe-módban voltak ténylegesen működőek? Ezek nélkül bármilyen más biztonsági intézkedés értelmetlen.

  • 4287 megtekintés

( sj | 2011. 09. 11., v – 12:40 )

mondjuk ez ugy lenne szep, ha a php is eljutna a VM koncepciojahoz, es virtualis gep (es nem fuggveny/modul/whatever) szinten korlatozhatnad, hogy mit tehet meg egy php program...

Viktor az eletrol es a halalrol

Nekem az is jó ha kernel szinten korlátozhatnám hogy mit tehet a www-data user. Mert azért a modulként futtatás lehetősége megmarad, tehát az apache processzek és ezzel együtt a php www-data felhasználóval fut. Nekem mindegy, csak valami legyen. Nem találok semmit arról hogy mivel gondolják ezt helyettesíteni.

Arra gondoltam hogy rádobni egy memória kvótát.(bár az az apache szervert nem védené az összeomlástól) Ezen kívül megmondani hogy mondjuk a www-data user csak a runfromphp csoportba tartozó binárisokat futtathatja. Meg lehetne ezt oldani. Csak hogyan?

Szerk:Nem is értem miért fut az apache külön felhasználóval, ha ennek az előnyeit nem lehet kihasználni.

Szerk2: Azt hiszem hamar rá fogok vetemedni, valami rsbac-féle megoldásra. Csak kicsit nehéz meglépni, mert nagyon új nekem, azt sem tudom hol kezdjek bele. Ráadásul XEN kernelt kéne fordítanom, hogy patch-elni tudjak. Ahhoz se nagyon füllik a fogam.

Gondoltam teszek egy próbát a suhosin néhány ígéretes opciójának beállítására. Például ez a suhosin.executor.include.allow_writable_files opció elég ígéretesnek látszik, hiszen modsecurity-vel már tiltom ezen fájlok közvetlen futtatását, milyen nagyszerű kiegészítés lehet ez!
Ki is próbálom, fehér képernyő fogad. Nagyszerű, blokkolta. Nézem a logot, semmi. Ezek szerint ha nem működik egy oldal, akkor nem fogom tudni hogy miért.
Lehet hogy valamit nem vettem észre. A leírásban csak az van hogy a syslog-ba mit logoljon. Az apache log ról szó sincs.

Szerk:Ez megoldotta: 


suhosin.log.syslog = 0
suhosin.log.sapi =511

sapi

( wladek1 | 2011. 09. 11., v – 15:55 )

Nem feltétlen értelmetlen. Értelmetlen az, amikor a fejlesztő user inputbol határozza meg teljesen az elérési utakat, s ezt a php -nak kell kipofoznia a safe_mode segítségével...

( janoszen v | 2011. 09. 11., v – 17:20 )

A safe_mode és az open_basedir úgy broken, ahogy van. Tessék (Fast)CGI-t használni és oprendszer szinten korlátozni a PHP lehetőségeit.

( taxy | 2011. 09. 11., v – 18:30 )

Jogosak a kritikák. Tényleg sok lehetséges megoldás van. Minden tiszteletem a fastcgi-nek, a különböző Advanced Access Controll megoldásoknak.

Csak hogy a körülmények világosak legyenek: Ez egy VPS, méghozzá a legolcsóbb 256Mb-os csomag. Szám szerint 133 virtualhost van rajta, aminek a többsége üres, a többin pedig jórészt joomla. Nincsenek felhasználók, az egész egy nagy "tolt fel-húzd le" CMS homokozó. Engem se fizetnek meg igazán, nem is nagyon veszem komolyan a munkát. Meg nincs is mit komolyan venni. A lényeg az lenne hogy a CMS férgek ne tudjanak szaporodni, és lehetőleg minél kevesebb jogot adjak mindenre, mert rajtam kívül más úgy se foglalkozik biztonsággal. Ilyen körülmények között szerintem a safe mode az ideális.

Az AllowOverride-ot természetesen mindig lehetséges minimumon tartom.
A chroot-ról annyit hogy egy másik helyen használtam már, de csak a helyet foglalja. Most mit védek azzal egy VPS-en? Az összes többi szolgáltatás kapcsolódik hozzájuk(mysql,postfix). Tehát ha a chroot-ba bejutottak akkor már olyan mindegy.(max annyi hogy ha loop partícióra rakom a /var/www-t, akkor ott partíció szinten tudom tiltani a futtatást, ha minden kötél szakad lehet hogy itt is megcsinálom, csak nehéz előre kiszámítani hogy mekkora legyen a loop partíció, aztán meg méretezhetem át folyton)

"A system, exec, shell_exec és passthru függvényeket is tiltod ugye?:)"

Az a sendmail paracs használatát szabotálná. Vagy mégsem?

Csak azért gondoltam, mert exec_dir-be kellett venni a sendmail könyvtárát különben nem működött.
De igazad lehet, mert Horde-val volt csak dolgom, és az mintha az exec függvényt használná a levélküldéshez, hogy miért, fogalmam sincs. De nem állok neki átírogatni az összes kretén alkalmazás, ha nemmmműűűködik ööee

Szerk: Ez olyan mint hogy sok alkalmazás használja az url_fopen-t, holott curl modullal ugyan azt megtehetné. Emiatt is sokat alkudoztam aztán megadtam magam.

Szerk2: Közben beugrott miért. A mail() függvénnyel nem lehet felüldefiniálni a boríték feladót. Azt csak a sendmail-nak lehet paraméterként megadni -f kapcsolóval. Ezzel is megszenvedtem.

Kiváló SMTP módot tud egy halom mai CMS, pl. a Joomla is. Ezt a horde-nak is ismernie kéne, ha haladnak a korral. Rögtön egy binárissal kevesebb.

A chroot roppant előnyös, mert minimumon tudod tartani a futtatásra elérhető cuccokat és szeparált lesz kicsit a MySQL-től is a dolog.

Chroot megvan. Kifejlesztettem egy FUSE modult, amivel automatikusan ki tudom válogatni hogy milyen fájlok kellenek az apache-nak(egy próba futtatás alkalmával), és szinte 0 tárhely mellett szimulálja azt. Szimbolikus linkek formájában gyűjti össze és tárolja a fájlneveket. Lehet majd közzé is teszem. Viszlát "safe mode".

Hogy ezzel az smtp-vel mi lesz azt nem tudom. Elég körülményes bevezetni a chroot-ba a socket fájlokat. Az lenne a legjobb ha a php tényleg beépítve támogatná az SMTP-t, de ez csak windows alatt igaz. Pedig milyen elegáns lenne ha egyszerűen csak tudná használni a localhost-ot. Valószínűleg ez lesz:SSMTP Igaz ez is bináris.