./+DEINSTALL: Permission denied

[Dan Lukes]

Miroslav Lachman napsal/wrote, On 05/31/06 09:45:
> Budu tedy co nejkonkretnejsi - ve vetsine pripadu mam nastarosti 
> servery, kde se provozuje web (Apache), databaze (MySQL,) mail 
> (Postfix), FTP a veci s timhle zamerenim souvisejici. Uzivatele tam 
> nemaji pristup k shellu, pouze FTP / HTTP upload. nosuid a noexec mam 
> minimalne na oddilu, kam uzivatele nahravaji svoje soubory pres FTP 
> (99.9% se jedna o soubory pro publikaci pres web). Tim nosuid a noexec 
> na dalsich oddilech se snazim branit pripadnemu napadeni skrz diru v 
> nekterem z nainstalovanych SW. 

	Ano, to je presne ten pripad, kdy ma smysl mit na HTTP/FTP data 
zvlastni partition a krome toho, ze v Apache proste nemam 
nakonfigurovanou moznost spoustet zadne cgi scripty ani php ani shtml 
ani nic podobneho (bud' vsude, nebo alespon v te casti stromu, kam smi 
"vnejsi" zapisovat) je na takove partition mozne pouzit noexec a nosuid.

> Co si tak vybavuji, tak napriklad awstats 
> (perlovy CGI pro generovani statistik z logu Apache) v minulosti 
> obsahovaly diru, kde utocnik mohl nahrat soubor do docasneho adresare a 
> odtamtud ho pres awstats spustit. Nevim o tom zadne vetsi podrobnosti, 
> takze ani nemam jistotu, ze by tomu nosuid, nebo noexec zabranili. 
> Zkratka se takovym podobnym utokum snazim vlozit do cesty co nejvic 
> prekazek to jde. Tedy zakazat to, co neni k nicemu jinemu potreba. 

	Coz ale neni tvuj pripad. Ty exec ve /var potrebujes. A ti, co 
pouzivaji qmail, nebo o cem to tu byla rec, ti take - takze ani jejich 
pripad to neni.

	A tak je proste potreba provest hlubsi analyzu problemu - prvni otazka 
je, zda preci jen nedokazu zajistit, abych onen /var mohl byt noexec - 
tim, ze "blokujici" programy nahradim, prekonfiguruji, prestanu 
pouzivat. To je cena za tuto metodu ochrany. A je treba rozhodnout, 
jestli ji mohu nebo nemohu zaplatit. Na tuhle otazku neexistuje 
univerzalni odpoved.

> Jelikoz jsem si do ted myslel (nebo to tak spis donedavna bylo), ze na 
> /var/db neni potreba suid ani exec, tak jsem tam mel nosuid a noexec a 
> vse fungovalo - az ted se objevuji problemy s +DEINSTALL.

	No, tak to je prekazka, ktera se jevi byt (alespon me) relativne snadno 
odstranitelna (=cena za jeji odstranitelna je mala a tedy pravdepodobne 
prijatelna)

>> 	Nebo behem instalace a deinstalace noexec flag odstranit.
> 
> Je pouziti mount -u -o current,exec /var/db
> a nasledne mount -u -o current,noexec /var/db
> bezpecne / bez vedlejsich ucinku pri pouziti na oddilu, se kterym se 
> neustale pracuje? 

	Teoreticky ano. V praxi ? Samozrejme, ze muze byt nekde v kodu OS 
chyba. Ano, ta operace je rizikova - jako vlastne kazda, ktera se se 
systemem provadi. Toto riziko je soucasti ceny za toto bezpecnostni 
opatreni.

	Neni to nijak exaktni statisticke zkoumani, ale nevybavuju si v zadnem 
pripade, ze by mi pouziti -u prineslo nejakou potiz. Pravda, nepouzivam 
ho nijak pravidelne (a vetsinou pridavam respektive ubiram 'async' 
nikoli 'noexec').

	Pokdu o tom nekde neco psali - je treba prozkoumat tento zdroj 
informace a pak se rozhodnout.

> Lze se nejak ucine branit vyse popsanym pripadum napadeni? 

	Zadne "vyse popsane" pripady se v tomto emailu neobjevily. Moznost, ze 
nejaky CGI obsahoval jakousi diry je sice zminena, ale neni to nijak 
popsane - co vlastne zneuzil a jak. Takze nelze rict, jestli by tomuto 
typu napadeni (kdyz ten typ nezname) slo zabranit zpusobem A nebo B. A 
jien utoky nejsou zmineny vubec, takze o tech se konkretne nelze bavit take.

	Ty ve skutecnosti hledas zpusob, jak se branit proti nespecifikovanym 
(nekonkretnim) napadenim. A na to neexistuje konkretni rada - jen 
nekonkretni. Maximalne omezit pro jednotlive komponenty OS rozsah 
cinnosti, ktere mohou delat (a co nejvice je od sebe co izolovat 
navzajem). Pritom je ale treba si uvedomit, ze omezeni znamena "omezeni" 
- a ze ta omezeni budou nejak omezovat nejen neznameho utocnika, ale 
uplne kazdeho. Takze je potreba zvazit, zda jsou takova omezeni jeste 
slucitelna s pozadovanou funkcnosti systemu - a pokud ne, zda lze nejak 
upravit funkcnost, nebo zda je treba se vzdat implementace daneho omezeni.

	Vim, ze to neni nijak konkretni odpoved. Ale na obecnou otazku lze 
malokdy ziskat konkreni odpoved. A v bezpecnosti to plati velmi silne - 
tam kolikrat i na docela dost konkretni otazku nelze ziskat zcela 
konkretni odpoved ...

	Existuje takova poucka - ze zacatku lze i s velmi malymi naklady i 
velmi vyrazne omezit rizika pro chraneny objekt. Postupne ale naklady 
rostou, posleze dokonce prudce rostou, ale soucasne prudce klesa mira 
omezeni rizika, kterou lze temito naklady dosahnout. Nakonec lze 
ohromnyni naklady omezit riziko jiz jen velmi nepatrne. Snazsi je to 
namalovat, nez popsat, ale to by v emailu nebylo trivialni.

	Na techto dvou krivkach je treba najit bod, kde naklady na dosazeni 
pozadovaneho stupne bezpecnosti, v porovnani s odhadovanymi skodami 
vzniklymi v souvislosti s uspesnym vyuzitim zbytkoveho rizika jsou v 
rovnovaze. A to je ucelna mira bezpecnosti, ktere je rozumne dosahnout - 
dosahovat vic je neekonomicke, dosahovat min nebezpecne. Pricemz 
"naklady" s emysli nejen naklady prime - je treba zapocitat vsechno. 
Vcetne vyssich naklady na udrzbu, vcetne snizene produktivity prace 
systemu a jeho uzivatelu (obe skupiny ty bezpecnostni opatreni mohou 
brzdit), vcetne mozne vyssi ceny odstraneni zavady a vypadku. Do rizika 
a s tim souvisejici mozne skody je naopak nutne pripocitat riziko mozne 
lidske chyby pro sprave sloziteho zabezpecovaciho mechanismu ci riziko 
umysleho poskozeni, ktere nebude ve slozitejsim systemu snadne odhalit.

	Kolikrat je lacinejsi zbytkove riziko dale nezmensovat, ale uzavrit na 
moznou skodu vhodne pojisteni ...

	U vas musite odhadnout jake hrozi skody v souvislosti s napadenim a z 
toho pak dovodit, jake prostredky a energii je jeste ucelne vynakladat 
do bezpecnostnich opatreni. To je u kazdeho chraneneho objektu jine (ono 
to vyse uvedene totiz neplati jen pro ochranu pocitacu, ale vlastne 
ochranu cehokoliv).

	Nicmene, uz jsem se asi dostal mimo ramec tema teto konference.

	Muzu ti na toto tema doporucit docela peknou prednasku ;-)


> Ma napriklad 
> smysl zacit studovat ACL / MAC? (mam o tom jen velice povrchni predstavu)

	Urcite to ma smysl. Jsou to metody, jak "jemne" nastavovat prava. 
Napriklad s pomoci mac_portacl (man mac_portacl) lze dosahnout toho, ze 
proces bude schopen zacit sitove poslouchat na konkretnim sitovem portu 
s cislem nizsim nez 1024 bez toho, ze bude potrebovat bezet jako 
superuzivatel. U tech daemonu, ktere startuji jako root prave jen proto, 
aby mohli bindnout takovy port se tim otevira moznost je vubec s 
takovymi pravy nespoustet a tim samozrejme omezit moznost, ze chybou v 
programu budou moci byt takova prava zneuzita.

	Treba takove anonymous-only FTP je typickym kandidatem na provoz v 
tomto rezimu. A WWW server muze byt docela dobre hned druhym. I named je 
naprosto jasny kandidat. S trochou prace i sendmail.

	Mezi mac-* jsou ale i jine zajimave moduly - fandy do bezpecnosti 
urcite musi nadchnout implementace BIBA a Bell-LaPadula  modelu 
integrity (ten druhy se obcas take oznacuje jako "military" a na FreeBSD 
je oznacen jako MLS). Ale jejich realne nasazeni je opravdu jen pro 
fajnsmekry, hracicky - a pak tam, kde je opravdu treba zajistit vysokou 
miru bezpecnosti predevsim nezi uzivateli navzajem (to, ze to soucasne 
zvysuje bezpecnost proti vnejsimu utocnikovi je zu spise doprovodny 
efekt). Implementova takove modely na realnem systemu je opravdu 
netrivialni mira prace - i kdyz - vysledek pak stoji opravdu zato (tedy, 
na systemu, kde za to stoji predevsim zpracovavana data).

	Myslim ale, ze vetsina clenu teto konference, me nevyjimaje, bezne 
spravuje systemy u kterych skoda souvisejici s uspesnym napadenim neni v 
absolutnim cisle nijak zavratna. A tomu by mela odpovidat pouzita 
zabezpecovaci opatreni - vyplati se nasazovat jen ta lacina. Jestli je 
'noexec' lacine opatreni ci nikoliv lze posoudit pouze ve zcela 
konkretnim pripade, obecne to mozne neni.

					Dan




-- 
Dan Lukes                                   SISAL MFF UK
AKA: dan at obluda.cz, dan at freebsd.cz,dan at kolej.mff.cuni.cz