Bezpecnost
Maaartin
1. Uzivatel si stahne muj prg ktery pouziva FB databazi do ktery se
ukladaji naky privatni data,
Jede to embedded, server se neistaluje. Je to tak bezpecny jaxou
bezpecny jeho soubory, coz staci.
2. Uzivatel si stahne uplne jiny prg, ktery instaluje FB servr,
pouziva defaultni heslo a je pristupny ze site.
To je samo o sobe v poradku, protoze ten jiny prg neuklada zadny data
co je potreba drzet v tajnosti.
3. Dohromady vznika ale prusvih, bo pres ten servr jsou dosazitelny i
privatni data ukladany mym programem.
Problem je realny, ten jiny prg muze byt cokoliv, ja znam dokonce
jeden realny priklad.
Ukladaji se tam naky vysledky mereni, ktery neni proc tajit a neni
duvod uzivatele obtezova zadavanim hesla.
Uzivatel ani nemusi vedet, ze se instaluje naky servr, proste vi, za
na tomhle compu se ukladaji data a na tomhle a tomhle se provadi a
zpracovava mereni a to mu staci.
Blby je, ze nic nepomuze i kdyby neslo o BFU ignorujicho zaklady
bezpecnosti.
Ukladat do DB sifrovany data nema pro me smysl - vyhledavani by neslo
tak jak potrebuju.
Strcit moju DB do sifrovanyho souboru (treba truecrypt) moc nepomuze,
bo v okamziku pouziti bude pristupna vsem.
Spolehat se na to, ze BFU nastavi spravny pristupoby prava je iluze.
Sifrovani databaze FB neumi - o duvodech (se kteryma souhlasim jen
castecne) se tu vedla dlouha diskuze.
Napada me jen jedno rozumny reseni - nejak zaridit, aby ta DB
nefungovala se servrem ale jen jako embedded.
Na to by mozna stacilo nejak trivialne pozmenit format ukladanych dat
(aby servr rekl "s tim nehraju") a pozmenit pouzivany DLL aby to
embedded jelo.
Snad jsem se vyjadril jasne. Je to blbost nebo si mam stahnout
zdrojaky FB a zkusit to?
peca
nevim, jake ma moznosti FB Embeded ohledne uzivatelskych opravneni
uvnitr databze, ale neslo by jit touto cestou? Tedy embeded databazi
vytvori, pouzivat atd, pod jinym uzivatelem, nez SYSDBA.
Druha vec je, ze pokud ma k PC pristup opravdu kdokoliv (treba po
siti), pak na nem jaksi nemuze bezet server s defaultnim
administratorskym uctem, ze. Takze na nainstalovanem serveru zakazat
SYSDBA, respektive mu nastavit jine heslo. To by snad ten merici SW mel
zvladnou, prihlasit se k databazi s jinym userem a heslem, nebo alespon
heslem.
Peca aka Petr Palicka
Maaartin
> nevim, jake ma moznosti FB Embeded ohledne uzivatelskych opravneni
> uvnitr databze, ale neslo by jit touto cestou? Tedy embeded databazi
> vytvori, pouzivat atd, pod jinym uzivatelem, nez SYSDBA.
jedine sysdba:masterke, ale i kdyby ne, tak to nejspis nepomuze, bu
sysdba muze vsecko.
> Druha vec je, ze pokud ma k PC pristup opravdu kdokoliv (treba po
> siti), pak na nem jaksi nemuze bezet server s defaultnim
> administratorskym uctem, ze.
nic tajnyho neni, tak proc ne. Muzeme s tim sice nesouhlasit, ale to
je asi tak vsechno co se s tim da delat.
> Takze na nainstalovanem serveru zakazat SYSDBA, respektive mu nastavit jine heslo.
ten ho muze naistalovat prede mnou nebo po me...
> To by snad ten merici SW mel zvladnou, prihlasit se k databazi s jinym userem a heslem, nebo alespon heslem.
pouzivajiciho FB aby to udelal poradne. Ten merici soft byl jen
priklad (se kterym mam okrajove neco malo spolecnyho) a tam snad bylo
nepouzivani hesla primo v zadani. Kdokoliv jiny muze pripadnou na tu
myslenku a obavam se ze to nebude zadna vyjimka.
Stejne tak muze byt kazdy prg pouzivajici jen embedded FB pro privatni
data ohrozen kazdym prg instalujicim servr kterymu je vsecko jedno.
Pavel Poles
Dne 15.12.2009 15:35, Maaartin napsal(a):
>
>> nevim, jake ma moznosti FB Embeded ohledne uzivatelskych opravneni
>> uvnitr databze, ale neslo by jit touto cestou? Tedy embeded databazi
>> vytvori, pouzivat atd, pod jinym uzivatelem, nez SYSDBA.
>>
> Prave ze AFAIK vubec zadny. Jestli si dobre vzpominam, tak to zere
> jedine sysdba:masterke, ale i kdyby ne, tak to nejspis nepomuze, bu
> sysdba muze vsecko
toho nesmi byt prazdny string.
Tzn. - vytvorit databazi pod jinym uzivatelem a zakazat SYSDBA pomoci role.
viz. napr. http://www.firebirdsql.org/manual/ufb-cs-embedded.html
Karel Rys
pristupova prava tak, aby do ni nemel Firebird Server pristup?
Pravda, nevim, jaky problem muze nastat, kdyz seberes prava uzivateli
"Local system" nebo pod cim Firebird standardne bezi.
Karel Rys
Maaartin
> Dne 15.12.2009 15:35, Maaartin napsal(a):> On Dec 15, 3:09 pm, peca<p...@email.cz> wrote:
>
> Embeded bere jakoukoliv kombinaci jmena a hesla, nicmene ani jedno z
> toho nesmi byt prazdny string.
> Tzn. - vytvorit databazi pod jinym uzivatelem a zakazat SYSDBA pomoci role.
nic, to by logicky melo znamenat ze nikdo nic nesmi a to je blbost.
Tez jsem si myslel ze RDB$ROLES je soucasti security2.fdb ci neceho
takovyho a asi neni.
> viz. napr.http://www.firebirdsql.org/manual/ufb-cs-embedded.html
Furt netusim jak na ty role.
On Dec 15, 7:10 pm, Karel Rys <del...@zas-me.cz> wrote:
> A nestacilo by te slozce, do ktere instalujes svuj program, upravit
> pristupova prava tak, aby do ni nemel Firebird Server pristup?
> Pravda, nevim, jaky problem muze nastat, kdyz seberes prava uzivateli
> "Local system" nebo pod cim Firebird standardne bezi.
nejsou. Tez si to nekdo muze naistalovat ze to pojede pod nim nebo tak
nejak.
Ivan Prenosil
:-)
Maaartin
update.
:-(
No i kdyby prosla, stejne bych nevedel jak dal. A v manualu jsem ani
"CREATE ROLE" nenasel.
Btw., je hezky ze k tomu existuje tolik dokumentace, ale nedala by se
udelat naka kompletni?
Na strance http://www.firebirdsql.org/index.php?op=doc je toho hafo
ale nic kde by se dlao neco najit.
A strejda taky nic (zatimco pro MySql uz roky nic jinyho nepouzivam,
je to rychlejsi nez hledat lokalne).
Pavel Poles
Furt netusim jak na ty role.CREATE ROLE SYSDBA; :-)This operation is not defined for system tables.Unsuccessful metadata update. :-(
takze bud musi byt databaze jeho a nebo nejdriv
GRANT ALL ON RDB$ROLES TO uzivatel pod SYSDBA, nebo jinym uzivatelem, ktery k tomu ma opravneni a pak az teprve udelat tu roli.
(Nezkousel jsem jestli to jde udelat kdyz jsi prihlasenej jako SYSDBA).
Pointa je ze pokud se pak k databzi pokusi prihlasit SYSDBA, tak mu to nepovoli, protoze v databazi je definovana role
se stejnym jmenem jako jmeno uzivatele.
RDB$ROLES je soucasti kazde jednotlive databaze, neni soucasti security.fdb - tam je jen seznam uzivatelu pro dany server.
Maaartin
> CREATE ROLE SYSDBA je spravne, nicmene prihlasenej uzivatel musi mit
> prava na RDB$ROLES,
user name SYSDBA could not be used for SQL role
> takze bud musi byt databaze jeho a nebo nejdriv |
>
> GRANT ALL ON RDB$ROLES TO uzivatel|
>
> pod SYSDBA, nebo jinym uzivatelem, ktery k tomu ma opravneni a pak az
> teprve udelat tu roli.
heslem "ua", udelal cvicne tabulku, nacpal daty, proslo. Na tom CREATE
ROLE SYSDBA to ale zdechlo.
> (Nezkousel jsem jestli to jde udelat kdyz jsi prihlasenej jako SYSDBA).
>
> Pointa je ze pokud se pak k databzi pokusi prihlasit SYSDBA, tak mu to
> nepovoli, protoze v databazi je definovana role
> se stejnym jmenem jako jmeno uzivatele.
> RDB$ROLES je soucasti kazde jednotlive databaze, neni soucasti security.fdb - tam je jen
> seznam uzivatelu pro dany server.
Ivan Prenosil
> > prava na RDB$ROLES,
>
> Furt to nejde, tentokrat s rozumnou hlaskou:
> user name SYSDBA could not be used for SQL role
Maaartin
Unsuccessful execution caused by a system error that precludes
successful execution of subsequent statements.
Your login @1 is same as one of the SQL role name. Ask your database
administrator to set up a valid Firebird login.
Otazkou je ovsem, jestli jsem si pomohl: Pokud je server uplne
otevreny (jako ze byt po instalaci toho vyse zminenyho "jinyho prg"
je),
tak muze SYSDBA vytvorit jinyho uzivatele... a jsme kde jsme byli.
Potreboval bych asi zakazat vsecky loginy do moji DB krome toho co
pouzivam embedded a
zarucit ze pod nim se nikdo neprihlasi bez myho hesla nebo ze ho nikdo
neuhodne jeho username.
Jiri Cincura
> 3. Dohromady vznika ale prusvih, bo pres ten servr jsou dosazitelny i
> privatni data ukladany mym programem.
Ja myslim, ze ten problem lezi uplne jinde. Vezmeme bod 3 a vyhodme
server a proste predpokladejme, ze nejaky SW ten soubor prekopiruje k
sobe a treba ho posle autorovi a ten se s tim popere.
Najednou problem neni v tom, ze nekdo nainstaluje server, ale proste
ze ten stroj neni zabezpeceny a kdyz mam fyzicky pristup k souboru,
muzu delat vicemene cokoli, at s tou DB udelas sebelepsi magii.
Dokonce i asymetricke sifrovani je v tomto pripade naprd, oboji muze
utocnik ziskat.
Pokud tomu chces zabranit aspon trochu, pred BFUckama, buildni si
vlastni fbembed.dll [1] a prehazej nejaky bajty treba v hlavicce nebo
tak neco, aby to regulerni FB nepochopil, ale tys to lehce
zmodifikoval. Ale pokud ti jde o opravdove zabezpeceni, musis prvne
zabezpecit ten stroj. Jinak je to vse jen falesny pocit bezpeci.
[1] Pripadne si mezi IO operace a fbembed vsad vlastni knihovnu a
prehazuj treba 10 na 01 a 01 na 10, proste jen prohazovat nejaky data,
tady transparentne pro fbembed.
--
Jiri {x2} Cincura (CTO x2develop.com)
http://blog.cincura.net/ | http://www.ID3renamer.com
Maaartin
> 2009/12/15 Maaartin <grajc...@seznam.cz>:
>
> > 3. Dohromady vznika ale prusvih, bo pres ten servr jsou dosazitelny i
> > privatni data ukladany mym programem.
>
> Ja myslim, ze ten problem lezi uplne jinde. Vezmeme bod 3 a vyhodme
> server a proste predpokladejme, ze nejaky SW ten soubor prekopiruje k
> sobe a treba ho posle autorovi a ten se s tim popere.
Prevazne nesouhlasim - pokud si nekdo muze nakopiruje ten soubor, tak
to znamena, ze cely ten comp je v pytli a to je problem ktery z
principu veci nemuzu a nemusim resit.
A to ze dvou duvodu:
1. Uzivatel zpristupnil (z blbosti ci gatesovym dopustenim) svoje data
a to se je vec se kterou tezko co nadelam.
Data ulozeny v DB ve kterych se ma hledat z principu nemuzou byt
sifrovany a cela vina tedy pada na uzivatele.
Treba tam ma i keylogger, a proti tomu opravdu nelze nic delat.
2. Ty privatni data co ukladam se vztahuji prevazne k souborum
uzivatele.
Kdyz je nekdo schopny precist soubor co nema, paxe da vychazet z
toho ze muze precist vsecko a tim padem neni co tajit.
> Najednou problem neni v tom, ze nekdo nainstaluje server, ale proste
> ze ten stroj neni zabezpeceny a kdyz mam fyzicky pristup k souboru,
> muzu delat vicemene cokoli, at s tou DB udelas sebelepsi magii.
> Dokonce i asymetricke sifrovani je v tomto pripade naprd, oboji muze
> utocnik ziskat.
Castecne souhlasim ale, kdyz
1. uzivatel musi pokazdy zadat heslo
2. tam neni keylogger
3. cela DB jako soubor je sifrovana
pak utocnik nema sanci.
Timto se dostavame k ty nekonecny diskuzi jesli ma ci nema smysl
sifrovani ve Firebirdu.
Podle me ma a sice uplne stejne jako ma smysl truecrypt.
Cim dyl o tom premyslim tim jsem si jistejsi.
A vlastne nevidim zadny duvod proc by to nemelo existovat.
> Pokud tomu chces zabranit aspon trochu, pred BFUckama, buildni si
> vlastni fbembed.dll [1] a prehazej nejaky bajty treba v hlavicce nebo
> tak neco, aby to regulerni FB nepochopil, ale tys to lehce
> zmodifikoval.
To zni rozumne. Jaxe to dela jsem si ted vygoglil, doufam ze mi to
pojede.
> Ale pokud ti jde o opravdove zabezpeceni, musis prvne
> zabezpecit ten stroj. Jinak je to vse jen falesny pocit bezpeci.
Ten stroj neni muj, takze nic nenadelam.
> [1] Pripadne si mezi IO operace a fbembed vsad vlastni knihovnu a
> prehazuj treba 10 na 01 a 01 na 10, proste jen prohazovat nejaky data,
> tady transparentne pro fbembed.
Jasne, muzu to treba jednoduse komplementovat nebo to muzu klidne i
sifrovat.
O tolik pomalejsi to zas neni a algoritmus neni slozity.
A nenapada me proc by to nemelo byt stejne opodstatneny jako to co
dela truecrypt - argumenty vitany.
Jiri Cincura
>> Ja myslim, ze ten problem lezi uplne jinde. Vezmeme bod 3 a vyhodme
>> server a proste predpokladejme, ze nejaky SW ten soubor prekopiruje k
>> sobe a treba ho posle autorovi a ten se s tim popere.
>
> Prevazne nesouhlasim - pokud si nekdo muze nakopiruje ten soubor, tak
> to znamena, ze cely ten comp je v pytli a to je problem ktery z
> principu veci nemuzu a nemusim resit.
> A to ze dvou duvodu:
> 1. Uzivatel zpristupnil (z blbosti ci gatesovym dopustenim) svoje data
> a to se je vec se kterou tezko co nadelam.
> Data ulozeny v DB ve kterych se ma hledat z principu nemuzou byt
> sifrovany a cela vina tedy pada na uzivatele.
> Treba tam ma i keylogger, a proti tomu opravdu nelze nic delat.
> 2. Ty privatni data co ukladam se vztahuji prevazne k souborum
> uzivatele.
> Kdyz je nekdo schopny precist soubor co nema, paxe da vychazet z
> toho ze muze precist vsecko a tim padem neni co tajit.
To je ale presne to co ted resis. At uz nove nainstalovany FB nebo
utocnik nebo xyz se dostane k souboru a je vymalovano. Je jedno jestli
to udelal user primo nebo neprimo. Porad je to jeho stroj, pod jeho
kontrolou. Pokud ty prava dokazes odeprit - coz asi ne, pac si
zminoval i FAT32 - je to jiny problem.
> Castecne souhlasim ale, kdyz
> 1. uzivatel musi pokazdy zadat heslo
> 2. tam neni keylogger
> 3. cela DB jako soubor je sifrovana
> pak utocnik nema sanci.
> Timto se dostavame k ty nekonecny diskuzi jesli ma ci nema smysl
> sifrovani ve Firebirdu.
> Podle me ma a sice uplne stejne jako ma smysl truecrypt.
> Cim dyl o tom premyslim tim jsem si jistejsi.
> A vlastne nevidim zadny duvod proc by to nemelo existovat.
Pokud se budeme bavit o sifrovani heslem uzivatele, pak ano. Jenze pak
je treba vesela diskuze co s indexy? Co na serveru s multiuser
pristupem atp.? Vetsinou to pak spadne na nejake lokalni sifrovani se
"zabezpecenym" klicem. Nerikam, ze to nema smysl, ale vetsina lidi si
mysli, ze jim to vyresi problem, ktery je vetsinou nekde jinde. Druha
strana mince je taky pocet developeru, kteri FB pouzivaji v komercnim
prostredi vs. pocet tech kteri prispivaji na vyvoj...
>> Ale pokud ti jde o opravdove zabezpeceni, musis prvne
>> zabezpecit ten stroj. Jinak je to vse jen falesny pocit bezpeci.
>
> Ten stroj neni muj, takze nic nenadelam.
Bohuzel ...
Maaartin
> Jenze pak je treba vesela diskuze co s indexy?
Nic, ty jsou v pohode.
Desifrovani se provadi v okazmiku nacitani do pameti, takze indexy a
vsecko funguje, bo zadny kus stavajiciho prg nikdy neuvidi zasifrovany
data.
Je to uplne stejny jako bys tahal data z truecryptonyho disku, je s
tou vyhodou ze jediny kdo vidi plaintext je FB.
> Co na serveru s multiuser pristupem atp.?
> Vetsinou to pak spadne na nejake lokalni sifrovani se "zabezpecenym" klicem.
Ty uvozovky si myslim nejsou na miste.
Ten klic muze byt ulozeny pro kazdyho uzivatele zasifrovany jeho
heslem.
To je pak uplne stejne bezpecny jako by se klic generoval primo z
hesla (jedinyho) uzivatele.
Samozrejme je pak otazka kam ten klic ukladat, nabizi se
1. security2.fdb
2. Naka rezervovana stranka ty sifrovany DB.
3. Jina DB.
Ja bych navrhoval 1 a sice proto ze jinak vzdy vznikne problem pri
zmene hesla uzivatele
Stacilo by neco jako
CREATE TABLE RDB$USER_KEYS (
RDB$UID INTEGER,
RDB$KEY VARCHAR(64) CHARACTER SET OCTETS NOT NULL,
CONSTRAINT PRIMARY KEY (RDB$UID, RDB$KEY),
CONSTRAINT FOREIGN KEY (RDB$UID) REFERENCES RDB$USERS (RDB$UID));
No a pro zasifrovanou tabulku by musely vyzkouset vsecky klice jednoho
uzivatele.
Pri zmene hesla by se vsecky jeho klice musely presifrovat.
Ale me osobne by stacilo sifrovani projednoho uzivatele.
> Nerikam, ze to nema smysl, ale vetsina lidi si mysli, ze jim to vyresi problem, ktery je vetsinou nekde jinde.
Resilo by to prinejmensim jeden zavazny problem: Kradez compu.
Dale by to resilo muj problem (uznavam ze na ten staci sifrovani
stylem ROT13).
Za predpokladu dobry implementace by to resilo vsecky problemy co
resilt lze,
to by se pak ale muselo vymakat i s ohledem na swap-file a podobne.
> Druha strana mince je taky pocet developeru, kteri FB pouzivaji v komercnim
> prostredi vs. pocet tech kteri prispivaji na vyvoj...
No to chapu, ale oproti nakym DB vyfikundacim je to celkem trivka.
Teda trivka pro nekoho kdo se vyzna v FB, me se jeste (za par minut)
nepodarilo proniknout k mistu kde se ctou a pisou data,
jediny vyskyt fread jsem nasel v src/jrd/ext.cpp a podle komentaru to
nebude ono.
Maaartin
http://www.ibphoenix.com/main.nfs?a=ibphoenix&s=1261073629:221409&page=ibp_source_guide
a v nem se docetl, ze v jrd je naky
IBSTDIO, ib_stdio.c
Generally just a wrapper for standard I/O. On Solaris, it's the BSD
standard io package. Solaris uses an eight bit file descriptor which
really makes openning a lot of TCP connections difficult. This affects
only buffered I/O.
To by mohlo byt ono. Chybka je v tom, ze zadny takovy soubor
neexistuje a sice podle ChangeLog-u uz vice nez 5 let. Samozrejme se v
nem uz nepise kam se veci z nej podely. No bomba.
Jiri Cincura
> To by mohlo byt ono. Chybka je v tom, ze zadny takovy soubor
> neexistuje a sice podle ChangeLog-u uz vice nez 5 let. Samozrejme se v
Jestli to nebude tim, ze ten dokument je 8 let starej...
> nem uz nepise kam se veci z nej podely. No bomba.
Mozna by stacilo se podivat jen do zdrojaku, jsou relativne citelne
strukturovane. "src\jrd\os\win32\" pripadne "winnt.cpp", tam se resi
primo IO.
Jiri Cincura
> Nic, ty jsou v pohode.
> Desifrovani se provadi v okazmiku nacitani do pameti, takze indexy a
> vsecko funguje, bo zadny kus stavajiciho prg nikdy neuvidi zasifrovany
> data.
Jenze otazkou je, jestli indexy taky sifrovat. A jak. A kdo vsechno (a
jak) ma mit k hodnotam pristup.
> Je to uplne stejny jako bys tahal data z truecryptonyho disku, je s
> tou vyhodou ze jediny kdo vidi plaintext je FB.
Jenze sifrovani disku je neco uplne jineho, zvlaste pak, pokud to je
jen pro jednoho usera.
> Ten klic muze byt ulozeny pro kazdyho uzivatele zasifrovany jeho
> heslem.
Hmm, a to ma pridat na bezpecnosti? Proc pak nepouzivat rovnou to heslo? ...
> Samozrejme je pak otazka kam ten klic ukladat, nabizi se
Samozrejme nikam neukladat. Klic musi byt oddelene, nejlepe reseny HW,
necitelny beznym SW (treba soubor atp.).
> 1. security2.fdb
> 2. Naka rezervovana stranka ty sifrovany DB.
> 3. Jina DB.
> Ja bych navrhoval 1 a sice proto ze jinak vzdy vznikne problem pri
> zmene hesla uzivatele
Jenze security2.fdb neni treba pro embedded. A na serveru je opet
lepsi si zabezpecit primarne ten stroj fyzicky, nez doufat, ze nekdo
slohne DB a nevydloube si uz klic z security2.fdb az tam FB sahne (v
jednu chvili vzdy bude v pameti heslo).
> No a pro zasifrovanou tabulku by musely vyzkouset vsecky klice jednoho
> uzivatele.
> Pri zmene hesla by se vsecky jeho klice musely presifrovat.
Coz je tedy velmi nesystemove.
> Ale me osobne by stacilo sifrovani projednoho uzivatele.
Jenze to je pro tebe (a nikdo ti nebrani si to naprogramovat). Ale
pokud to chces dat jako regulerni feature, musi to byt rozumne
navrzene a funkcni ve vice nez jednom pripade...
> Resilo by to prinejmensim jeden zavazny problem: Kradez compu.
> Dale by to resilo muj problem (uznavam ze na ten staci sifrovani
> stylem ROT13).
> Za predpokladu dobry implementace by to resilo vsecky problemy co
> resilt lze,
> to by se pak ale muselo vymakat i s ohledem na swap-file a podobne.
To je bohuzel ten spatny pristup. Jednak to muzes rovnou sifrovat na
urovni NTFS a neresit to v DB, nebo celej disk. A jednak fyzicka
kradez neni IMO vec co ma primarne resit engine. To si ma poresit
admin a pokud neni, tak aplikace/user.
> No to chapu, ale oproti nakym DB vyfikundacim je to celkem trivka.
> Teda trivka pro nekoho kdo se vyzna v FB, me se jeste (za par minut)
> nepodarilo proniknout k mistu kde se ctou a pisou data,
> jediny vyskyt fread jsem nasel v src/jrd/ext.cpp a podle komentaru to
> nebude ono.
Jestli myslis, ze je to trivka, potom ses hodne mimo ...
Jiri Cincura
2009/12/18 Jiri Cincura <dis...@cincura.net>:
>> No to chapu, ale oproti nakym DB vyfikundacim je to celkem trivka.
>> Teda trivka pro nekoho kdo se vyzna v FB, me se jeste (za par minut)
>> nepodarilo proniknout k mistu kde se ctou a pisou data,
>> jediny vyskyt fread jsem nasel v src/jrd/ext.cpp a podle komentaru to
>> nebude ono.
>
> Jestli myslis, ze je to trivka, potom ses hodne mimo ...
Navrhnout sifrovani, tak aby bylo prirozene zalozene na rozumnem
sifrovani, nebylo pomale a fungovalo i pro sdilene kusy dat v pameti a
pokryvalo vetsinu potreb je IMO prace na pul roku az rok pro jednoho
core vyvojare. Nehlede na plno veci, ktere se musi politicky
rozhodnout, jak se maji chovat a obrovske mnozstvi okrajovych pripadu,
ktere se vynori. A to cele jeste musis zabalit do uceleneho reseni s
pouzitelnym nastavenim a udrzbou/spravou.
Jiri Cincura
.NET, Java, Perl, Python, PHP, <a co ja vim co jeste>.
Maaartin
Snad budes mit silu precist co jsem napsal, neni to zrovna kratky.
A mozna te i presvedcim.
> Jestli to nebude tim, ze ten dokument je 8 let starej...
To by mohlo souviset. :D Ber to jako moje povzdechnuti nad stavem
dokumentace.
Je jasny ze drzet ji aktualni stoji silene moc casu, ale treba doxygen
by mohl vyrazne pomoct.
> Mozna by stacilo se podivat jen do zdrojaku, jsou relativne citelne
> strukturovane. "src\jrd\os\win32\" pripadne "winnt.cpp", tam se resi
> primo IO.
Tech par minut co jsem tomu zatim venoval nestacilo. Diky.
> Jenze otazkou je, jestli indexy taky sifrovat. A jak.
Odpovedi je "ano aj". Brano doslova:
Pokud indexy nezasifrujes, taxto projel, bo v nich jsou evtl. tez
citlivy data.
Pokud jo, taxto projel, bo nebudou fungovat.
ALE: Ja psal "Je to uplne stejny jako bys tahal data z
truecryptovanyho disku".
Tedy sifrovat se bude vsecko ale pouze na disku.
Takze indexy budou na disku zasifrovany a v pameti ne.
Takze to bude bezpecny a indexy budou fungovat.
> A kdo vsechno (a jak) ma mit k hodnotam pristup.
Hmmm, to je komplikace kterou jsem se zatim nezabyval.
Pro embedded mi to muze byt jedno.
> Jenze sifrovani disku je neco uplne jineho, zvlaste pak, pokud to je jen pro jednoho usera.
Ale truecrypt neni pro jednoho juzra.
Ten pripoji disk viditelny pro vsechny a dalsi pristup je pak reseny
pomoci opravneni OS.
Tady by to bylo totez a dalsi pristup by byl reseny pomoci opravneni
FB.
> > Ten klic muze byt ulozeny pro kazdyho uzivatele zasifrovany jeho heslem.
> Hmm, a to ma pridat na bezpecnosti?
Nema! Nemuze a nemusi. Je to tak ale treba delat, viz nize.
> Proc pak nepouzivat rovnou to heslo? ...
Ktery heslo kdyz mas vice uzivatelu?
Tohle je standardni postup kdyz sces zpristupnit jednu vec pro vice
lidi.
Zasifrujes vsecko jednim klicem a ten zasifrujes pro kazdyho
uzivatele.
Tak to dela treba PGP.
> Samozrejme je pak otazka kam ten klic ukladat, nabizi se
> Samozrejme nikam neukladat.
> Klic musi byt oddelene, nejlepe reseny HW, necitelny beznym SW (treba soubor atp.).
Ale jo.
1. To ukladani je treba pokud nesces uzivatele nutit zadavat krome
svyho hesla jeste jedno.
2. To ukladani nesnizuje bezpecnost pokud se klic uklada zasifrovane.
Samozrejme veci jako HW klic jsou dobry, ale kdyz by se mely pouzit
tak jinde.
> Jenze security2.fdb neni treba pro embedded.
To je v poradku.
Pro embedded by se ten klic odvodil primo z hesla uzivatele (ktery
IMHO jinak nehraje zadnou roli).
Pro server by se to delalo jaxem psal.
> A na serveru je opet lepsi si zabezpecit primarne ten stroj fyzicky, nez doufat,
> ze nekdo slohne DB a nevydloube si uz klic z security2.fdb az tam FB sahne
> (v jednu chvili vzdy bude v pameti heslo).
Fyzicky zabezpeceni je iluze. Vykrast treba banku je radove jednodussi
nez craknout AES-128.
To prvni se stalo uz tisickrat to druhy jeste ne.
Pokud delas prg pouzivajici FB a jedouci u zakaznika, pak nad fyzickym
zabezpecenim nemas zadnou kontrolu.
To heslo v pameti je problem, pocitejme ale s tim ze nikdo neodnese
server bez toho aby se vymazala pamet.
Nic jinyho nam nezbyva. Dokazu si predstavit jednoduchy zarizeni pri
vloupani resetujici pocitac.
> > Pri zmene hesla by se vsecky jeho klice musely presifrovat.
> Coz je tedy velmi nesystemove.
Mas lepsi napad? Ja ne.
Vadi to necemu?
> > Ale me osobne by stacilo sifrovani pro jednoho uzivatele.
> Jenze to je pro tebe (a nikdo ti nebrani si to naprogramovat). Ale
> pokud to chces dat jako regulerni feature, musi to byt rozumne
> navrzene a funkcni ve vice nez jednom pripade...
Nevim kolika lidem by to pomohlo, ale urco bych nebyl jediny.
Kolik je procent lidi kterym staci single-user embedded FB?
> To je bohuzel ten spatny pristup. Jednak to muzes rovnou sifrovat na
> urovni NTFS a neresit to v DB, nebo celej disk.
No, ale to neresi muj problem. Navic
> The support of EFS is not available in Basic, Home and MediaCenter versions of Windows, and must be activated...
Opet nic co by se dalo cekat od kazdyho BFU.
> A jednak fyzicka kradez neni IMO vec co ma primarne resit engine.
> To si ma poresit admin a pokud neni, tak aplikace/user.
Pokud delas prg pro kazdyho BFU taxe nemuzes spolehat na admina.
Pri sifrovani na urovni aplikace nelze rozumne vyhledavat (viz
sifrovani indexu).
Zbyva pouze sifrovani souboru delany OS (nelze vzdy), jinym prg
(nepohodlny) nebo primo FB.
> Jestli myslis, ze je to trivka, potom ses hodne mimo ...
I to je mozny.
> Navrhnout sifrovani, tak aby bylo prirozene zalozene na rozumnem sifrovani, nebylo pomale
Navrhnout sifrovani je mnohem slozitejsi.
Nastesti uz je to davno hotovy, tady se hodi totez co pouziva
truecrypt (XTS mode + treba AES).
Rychlost je a neni problem.
Ma stara bedna zvlada sifrovat 40 MB/s zatimco hadr zvlada 50 MB/s.
Takze to zpomaluje a procesor je v pytli.
Ma nova bedna zvlada sifrovat 450 MB/s zatimco hadr zvlada 200 MB/s.
Takze to neni poznat a 3.5 jadra se flaka.
Tendence je jasna.
> a fungovalo i pro sdilene kusy dat v pameti a
> pokryvalo vetsinu potreb je IMO prace na pul roku az rok pro jednoho core vyvojare.
Pocitam s tim, ze data v pameti jsou pod kontrolou FB.
Pokud nekdo vleze na comp a ma pristup k tvoji pameti, pak ti nepomuze
ani svecena voda.
> Nehlede na plno veci, ktere se musi politicky rozhodnout, jak se maji chovat a obrovske mnozstvi okrajovych pripadu,
> ktere se vynori. A to cele jeste musis zabalit do uceleneho reseni s pouzitelnym nastavenim a udrzbou/spravou.
No jiste, problemu je vzdycky dost.
S timto argumentem se ale dostaneme k tomu ze nema smysl delat vubec
nic.
To co navrhuju je relativne jednoduchy.
Tim ze se DB sifruje jako celek odpada vetsina problemu ktery mas kdyz
sifrujes treba na urovni sloupcu.
Samozrejme ze tim neziskas totez, sifrovani na urovni sloupcu ma svoje
vyhody, jenomze to je vec kterou si muzes udelat i v aplikaci.
A nefunguji i nej indexy (krome testu na rovnost), coz je problem.
Na strance
www.cgisecurity.com/database/oracle/pdf/f5crypt.pdf
je hafo informaci i pripadu k cemu se sifrovani nehodi.
Stale si myslim ze to co navrhuju je rozumny.
> A aby toho nebylo malo, tak to musi podporovat i klientske knihovny -
> .NET, Java, Perl, Python, PHP, <a co ja vim co jeste>.
Naopak - vse bude transparentni tak ze na tomhle miste sifrovani
nebude oznat.
Je treba se starat o tydle veci:
Servr i embedded:
- Vytvoreni sifrovany DB: To jde treba zasifrovanim existujici DB
nakym externim toolem. To je jediny misto kde uzivatel musi sam neco
delat.
- Cteni stranky z disku: Desifrovani, pokud se jedna o sifrovanou DB.
- Psani stranky na disk: Desifrovani, pokud se jedna o sifrovanou DB.
Embedded:
- Prihlaseni uzivatele: Z jeho hesla se primo odvodi klic k DB.
Servr:
- Prihlaseni uzivatele: Pomoci jeho hesla se odsifruji klice ulozeny v
security2.fdb. Vsechny tyto klice zustavaji v pameti i s informaci
ktery uzivatel ma ktery klic.
- Odhlaseni uzivatele: Kdyz se odhlasi posledni uzivatel majici klic k
dany DB, taxe tento klic odstrani z pameti.
- Prvni pripojeni k souboru: Pokud hlavicka nesedi, paxe predpoklada
ze je sifrovana a zkusi se desifrovat vsemi klici co jsou k dispozici.
Informace o tom ktery klic sedi se ulozi.
- Kazdy pripojeni k souboru: Krome normalniho testu pristupovych prav
se otestuje jestli uzivatel ma platny klic. Timto jsou sifrovany
soubory chraneny i pro pripad spatnyho nastaveni prav ci nekoho kdo
muze menit prava.
Jiri Cincura
> Ale truecrypt neni pro jednoho juzra.
> Ten pripoji disk viditelny pro vsechny a dalsi pristup je pak reseny
> pomoci opravneni OS.
> Tady by to bylo totez a dalsi pristup by byl reseny pomoci opravneni
> FB.
Takze jakmile ten stroj nekdo nabootuje a zna heslo, tak, pokud maji
uzivatele prava, vidi data? Tj. TrueCrypt ma jen jedno "master" heslo?
Neznam TrueCrypt, takze netusim. To muze byt docela problem, pokud
jeden z tech useru to heslo zkompromituje. :(
> Ktery heslo kdyz mas vice uzivatelu?
Na to jsem prave narazel.
> Tohle je standardni postup kdyz sces zpristupnit jednu vec pro vice
> lidi.
> Zasifrujes vsecko jednim klicem a ten zasifrujes pro kazdyho
> uzivatele.
To je ale docela serious problem z pohledu robustnosti. Pokud totiz
ucet jednoho usera bude prolomen, da se dostat ke klici. Potom uz
staci stahnout FB (ano, bacha je to open source) a zakomentovat
testovani opravneni na urovni DB a hned je vymalovano.
> To je v poradku.
> Pro embedded by se ten klic odvodil primo z hesla uzivatele (ktery
> IMHO jinak nehraje zadnou roli).
Potom je ale problem, kdyz se k embedded DB pripoji dva useri s ruznym
heslem (ackoli se ignoruje, klic by se odvodil spatne).
> Mas lepsi napad? Ja ne.
S timto resenim ne.
> Vadi to necemu?
Vadi. To je jako kdyby se pri vlozeni noveho zaznamu musel cely index
prepocitat. Indexy funguji, daji se pouzit na hledani, ale celkove je
to navrzene blbe.
> Nevim kolika lidem by to pomohlo, ale urco bych nebyl jediny.
A taky je mraky instalaci FB, kde je tohle neakceptovatelne.
> Pokud delas prg pro kazdyho BFU taxe nemuzes spolehat na admina.
> Pri sifrovani na urovni aplikace nelze rozumne vyhledavat (viz
> sifrovani indexu).
Pokud je to totalni BFU, tak chvili po instalaci budes muset vymyslet
zadni vratka, pac nekdo zapomene heslo a k datum se uz nikdy nedostane
a bude drzkovat. A pak na tohle nekdo prijde a zneuzije. :)
> Navrhnout sifrovani je mnohem slozitejsi.
> Nastesti uz je to davno hotovy, tady se hodi totez co pouziva
> truecrypt (XTS mode + treba AES).
Nemyslel jsem algoritmus, ale implementaci v enginu. Klasicky
pozadavek je treba sifrovani na urovni sloupcu, vynechani blob stranek
atp. K tomu jeste FB pouziva careful writes, takze opet dost casu na
premysleni co kdy a kam muze tect. A to do toho netaham (shared) page
cache atd.
> Rychlost je a neni problem.
> Ma stara bedna zvlada sifrovat 40 MB/s zatimco hadr zvlada 50 MB/s.
> Takze to zpomaluje a procesor je v pytli.
> Ma nova bedna zvlada sifrovat 450 MB/s zatimco hadr zvlada 200 MB/s.
> Takze to neni poznat a 3.5 jadra se flaka.
> Tendence je jasna.
To je ale cisty vykon. Kdyz treba budes sifrovat index, muze se stat,
ze jej budes muset pulku precist (a tedy desifrovat), prebalancovat a
pak zpatky zasifrovat. Musi se pak udelat mraky testu, zkouseni kam co
dat atp. Zadna sranda, zvlaste kdyz DB jsou vetsinou ty nezatizenejsi
casti systemu.
> No jiste, problemu je vzdycky dost.
> S timto argumentem se ale dostaneme k tomu ze nema smysl delat vubec
> nic.
S aktualnimi zdroji to bohuzel k takto velkym vecem konverguje. :(
> To co navrhuju je relativne jednoduchy.
Tak sup sem s tim. A ne budes opisovat z RedSoft implementaci. ;)
> Naopak - vse bude transparentni tak ze na tomhle miste sifrovani
> nebude oznat.
Kdyz uz sifrovani, tak sifrovani i wire protocolu. To by bylo polovicate reseni.
> Je treba se starat o tydle veci:
Vetsinu veci jsme uz rozebrali vyse. Nicmene nechci tvrdit, ze to
nemuzes implementovat nebo navrhnout v devel listu nebo dokonce
zasponzorovat.
Jiri Cincura
nemelo by se to implementovat. Jen, ze je to prudce netrivialni na
mnoha frontach a jeste k tomu nejsou zdroje. Plus samozrejme stale
jsou tu dulezitejsi veci (at uz dulezitejsi definujeme jakkoli).
Maaartin
truecrypt /v c:\nakysoubor /l x
(coz samozrejme jde i klikat) ono se to zepta na heslo a pak vytvori
disk x jehoz zasifrovany image je v c:\nakysoubor.
Image muze byt soubor nebo cela partition.
Jde to i tak ze to bootuje ze zasifrovany partition po zadani hesla.
V kazdym pripade vznikne pod Smejdama normalne se chovajici novy
pismenko.
> Tj. TrueCrypt ma jen jedno "master" heslo?
Pro kazdy disk image jeden, ja mam jeden pro praci a jeden soukromy.
> Neznam TrueCrypt, takze netusim. To muze byt docela problem, pokud
> jeden z tech useru to heslo zkompromituje. :(
Jednotkou sifrovani u toho co scu by je jedna databaze (xxx.fdb).
Bud k ni mas pristup nebo nemas, kdyz to jeden juzer podela, tak
smula.
V tomhle by sifrovani jednotlivych tabulek ci dokonce sloupcu bylo
teoreticky lepsi,
podle zakona schvalnosti by to ale vyslo nastejno.
> > Tohle je standardni postup kdyz sces zpristupnit jednu vec pro vice lidi.
> > Zasifrujes vsecko jednim klicem a ten zasifrujes pro kazdyho uzivatele.
> To je ale docela serious problem z pohledu robustnosti. Pokud totiz
> ucet jednoho usera bude prolomen, da se dostat ke klici. Potom uz
> staci stahnout FB (ano, bacha je to open source) a zakomentovat
> testovani opravneni na urovni DB a hned je vymalovano.
Ano a ne. Pokud mas vlastni xxx.fdb ke kterymu mas pristup jenom ty,
taxe ti nemuze nic stat,
i kdyz to pojede na masine kde je ten prolomeny juzr (i kdyby to byl
SYSDBA).
Samozrejme pokud nekdo nainstaluje treba hacknuty FB ukladajici hesla
nebo muze lezt do pameti,
pak mas smulu. Na to ale neexistuje vubec zadny reseni.
> > Pro embedded by se ten klic odvodil primo z hesla uzivatele
> > (ktery IMHO jinak nehraje zadnou roli).
> Potom je ale problem, kdyz se k embedded DB pripoji dva useri s ruznym
> heslem (ackoli se ignoruje, klic by se odvodil spatne).
Pro embedded musi pouzit stejny heslo.
Nedivej se na to jako na heslo uzivatele ale na heslo k tomu xxx.fdb.
> Mas lepsi napad? Ja ne.
S timto resenim ne.
> > Vadi to necemu?
> Vadi. To je jako kdyby se pri vlozeni noveho zaznamu musel cely index prepocitat.
> Indexy funguji, daji se pouzit na hledani, ale celkove je to navrzene blbe.
Podle me nevadi.
I kdyby kazdy menil svoje heslo 10x denne, stale je velmi vyjimecna
udalost a na rychlosti vubec nezalezi.
> > Nevim kolika lidem by to pomohlo, ale urco bych nebyl jediny.
> A taky je mraky instalaci FB, kde je tohle neakceptovatelne.
Mozna. V kazdym pripade by to byla neskodna ficurka.
Dokud dany xxx.fdb nezasifrujes, tak vse jede jak bylo.
Pokud ty si zasifrujes vlastni xxx.fdb, taxe to ostatnich stale
netyka.
A tebe vlastne taky ne, pojede to stejne jako driv (malinko pomaleji).
Pokud k nema das pristup nekomu jinymu (to je vec kterou jsem v
seznamu zapomnel),
tak to furt neni problem.
> Pokud je to totalni BFU, tak chvili po instalaci budes muset vymyslet zadni vratka,
> pac nekdo zapomene heslo a k datum se uz nikdy nedostane a bude drzkovat.
Nebudu. Drzkovat muze ale ma smulu. Bud sce bezpecny data nebo ne.
Kdyz nesce, tak at to nepouziva, kdyz sce, tak at nedrzkuje.
> A pak na tohle nekdo prijde a zneuzije. :)
Samozrejme. Proto zadna rozumna firma backdoors nedela.
Kdyz zapomenes heslo truecryptu, pak jediny co ti pomuze je pomodlit
se aby sis vzpomnel.
> > Nastesti uz je to davno hotovy, tady se hodi totez co pouziva truecrypt (XTS mode + treba AES).
> Nemyslel jsem algoritmus, ale implementaci v enginu.
> Klasicky pozadavek je treba sifrovani na urovni sloupcu, vynechani blob stranek atp.
To je jiny problem, predpokladam ze o pekny kus slozitejsi.
> K tomu jeste FB pouziva careful writes, takze opet dost casu na premysleni co kdy a kam muze tect.
> A to do toho netaham (shared) page cache atd.
Stale predpokladam ze pri sifrovani celyho xxx.fdb (narozdil od
ruznych sloupcovych vychytavek) to nehraje roli, souhlasis?
> Rychlost je a neni problem.
> Ma stara bedna zvlada sifrovat 40 MB/s zatimco hadr zvlada 50 MB/s.
> Takze to zpomaluje a procesor je v pytli.
> Ma nova bedna zvlada sifrovat 450 MB/s zatimco hadr zvlada 200 MB/s.
> Takze to neni poznat a 3.5 jadra se flaka.
> Tendence je jasna.
> To je ale cisty vykon. Kdyz treba budes sifrovat index, muze se stat,
> ze jej budes muset pulku precist (a tedy desifrovat), prebalancovat a
> pak zpatky zasifrovat.
To je ale jedno - vsechno to poleze z disku (a zpet) ani ne polovicni
rychlosti nez co zmakne jedno jadro.
Brzou bude disk a vytizeni procesoru nebude problem.
Je to analogicky k defragmentaci truecryptovanyho disku - tam taky
nepoznam rozdil k normalnimu.
> Musi se pak udelat mraky testu, zkouseni kam co dat atp.
> Zadna sranda, zvlaste kdyz DB jsou vetsinou ty nezatizenejsi casti systemu.
Jo.
> S aktualnimi zdroji to bohuzel k takto velkym vecem konverguje. :(
Co se da delat.
> > To co navrhuju je relativne jednoduchy.
> Tak sup sem s tim. A ne budes opisovat z RedSoft implementaci. ;)
No az/jestli to udelam tak to tam urco soupnu.
Jako prvni vec zkusim tu dekompatibilizaci aby mi na to nemohl servr.
> Kdyz uz sifrovani, tak sifrovani i wire protocolu. To by bylo polovicate reseni.
Sifrovani protokolu je fajn vec, ale znamena to praci i na klientech.
Pomaha to bezpecnosti ale uplne jinak, napriklad ti to pri kradezi
compu nepomuze ani trochu.
Navic se bez toho da zit bo existuji veci jak SSL, VPN, ...
> Vetsinu veci jsme uz rozebrali vyse. Nicmene nechci tvrdit, ze to
> nemuzes implementovat nebo navrhnout v devel listu nebo dokonce
> zasponzorovat.
Zatim diky za rozbor, az budu mit cas taxe na to kouknu poradne a paxe
uvidi.
> Nevim, jestli jsem to uz nepsal, ale nerikam, ze sifrovani je blbost a
> nemelo by se to implementovat. Jen, ze je to prudce netrivialni na
> mnoha frontach a jeste k tomu nejsou zdroje. Plus samozrejme stale
> jsou tu dulezitejsi veci (at uz dulezitejsi definujeme jakkoli).
V tom se jiste shodnem.
Vlastne to co navrhuju je "I/O Based Encryption" z
http://db.apache.org/derby/binaries/jta-WE15.pdf
akorat tam nemaji ten napad s pouzitim hesla uzivatele soucasne pro
generovani resp. desifrovani klice k xxx.fdb.
Pavel Cisar v zajimavym vlakne
http://odbornici.dbsvet.cz/?p=37#comments
napsal ze "není tedy problém jej o libovolný systém dle vasich potreb
rozsírit (v podstate je to triviální, problém je jen v managementu
klícu).".
Jednua vec na FB nechapu: Omezeni hesla na 8 znaku.
To neni zrovna moc, kdyz se pouziji maly i velky pismena i cislice,
taxe dostavame na zhruba 2**48 moznosti,
coz muze byt proklate malo, zejmena pokud nekdo ukradne security.fdb a
hraji si s ni doma.
Teda zalezi na tom jaxlozite se ulozeny heslo hashuje (password
strengtening) - mam pocit, ze trivialne.
Jiri Cincura
> Bud k ni mas pristup nebo nemas, kdyz to jeden juzer podela, tak
> smula.
LOL
> Ano a ne. Pokud mas vlastni xxx.fdb ke kterymu mas pristup jenom ty,
No vsak si ale rikal, ze na opravneni spolehat nemuzes. Jednak to
BFUcko nikdy spravne nenastavi (a nekdy ani admin) a jednak prej obcas
jedes i na FAT32.
> Nedivej se na to jako na heslo uzivatele ale na heslo k tomu xxx.fdb.
Aha. No to je pak docela dumb. Nehlede na to, ze by to musely zacit
zaroven podporovat vsechny klientske knihovny.
> Stale predpokladam ze pri sifrovani celyho xxx.fdb (narozdil od
> ruznych sloupcovych vychytavek) to nehraje roli, souhlasis?
Jo, ale to necekej implicitne ve FB. Tohle neni dotazene, ani
"enterprise ready".
> Brzou bude disk a vytizeni procesoru nebude problem.
Nektere DB jsou umistene na RAM discich a pak uz by to mohlo byt znat.
Nicmene jiste obeti musi samozrejme ten kdo to zapne ocekavat. Jen
jsem tim chtel rict, ze cisty vykon disku vuci CPU nemusi byt v tomto
pripade rozhodujici.
> Jako prvni vec zkusim tu dekompatibilizaci aby mi na to nemohl servr.
Hlavne nikde nerikej detaily. Pac jestli ukladas *fakt* dulezity data,
tak nekdo FB upravi stejne a je to v riiti. :)
> Sifrovani protokolu je fajn vec, ale znamena to praci i na klientech.
> Pomaha to bezpecnosti ale uplne jinak, napriklad ti to pri kradezi
> compu nepomuze ani trochu.
Jo.
> Navic se bez toho da zit bo existuji veci jak SSL, VPN, ...
To se da zit i bez sifrovani DB. :D Muzes to dat na sifrovanej disk.
> Jednua vec na FB nechapu: Omezeni hesla na 8 znaku.
> To neni zrovna moc, kdyz se pouziji maly i velky pismena i cislice,
> taxe dostavame na zhruba 2**48 moznosti,
> coz muze byt proklate malo, zejmena pokud nekdo ukradne security.fdb a
> hraji si s ni doma.
> Teda zalezi na tom jaxlozite se ulozeny heslo hashuje (password
> strengtening) - mam pocit, ze trivialne.
Jo, to je tam jeste z predvalecny doby. A 8 fakt je to proklate malo.
A vzhledem k tomu, ze po dratech jde heslo taky otevreny, je to dira
jako prase.
Maaartin
> LOL
Umis si predstavit ze sdilis s nekym data, ten nekdo je vyzvani a
presto budou bezpecny? Ja ne.
Tohle je stejna situace, heslo neheslo.
Jediny na cem se da zapracovat je granularita.
Kdyz se pracuje na urovni disku je vysledek zvaneni horsi nez kdyz se
pracuje na urovni policek tabulky.
Muj navrh je uprosted. Mate spolecny.fdb a jenomTvoje.fdb, on vyzvani
heslo k spolecny.fdb, jenomTvoje.fdb zustava v suchu.
> > Ano a ne. Pokud mas vlastni xxx.fdb ke kterymu mas pristup jenom ty,
> No vsak si ale rikal, ze na opravneni spolehat nemuzes.
> Jednak to BFUcko nikdy spravne nenastavi (a nekdy ani admin) a jednak prej obcas jedes i na FAT32.
Ano! Ale to jsme se nepochopili, ten pristup nebude kontrolovan
opravnenim ale sifrovanim.
Vidim ze to sce priklad (pseudosyntaxe):
CREATE DATABASE jenomTvoje.fdb;
ENCRYPT DATABASE jenomTvoje.fdb "jenomTvojeHeslo";
GRANT SELECT ON jenomTvojeHeslo.fdb TO *; // neni problem, mame heslo
CREATE DATABASE spolecny.fdb;
ENCRYPT DATABASE spolecny.fdb "spolecnyHeslo";
GRANT SELECT ON spolecny.fdb TO *; // neni problem, mame heslo
GRANT PASSWORD "spolecnyHeslo" ON spolecny.fdb TO zvanil;
A zvanil ho vyzvanil. Vsem. Takze spolecny.fdb si muze precist kazdy.
Ale jenomTvoje.fdb zustava nadale jenom tvoje, chraneny heslem.
> > Nedivej se na to jako na heslo uzivatele ale na heslo k tomu xxx.fdb.
> Aha. No to je pak docela dumb.
V cem je to horsi nez zadavat heslo co se k nicemu nepouzije?
Pokud polezes na jenomTvoje.fdb jako embedded, pak zadas jako heslo
"jenomTvojeHeslo" a z nej si primo vygeneruje klic.
Pokud na to polezes pres servr, pak musis pri prvotnim sifrovani DB
nebo dodatecne ulozit do security2.fdb ten klic k ty DB zasifrovany
tvym uzivatelskym heslem.
Kdyz se prihlasis xervru (svym uzivatelskym heslem), paxi to servr
pomoci nej odsifruje a ziska "jenomTvojeHeslo".
Takze servr bude schopny pristupovat k jenomTvoje.fdb.
Dale si zapamatuje ze ten klic ma od tebe a proto te k tomu pusti.
Presneji receno pusti k tomu kazdyho kdo ma ten klic ulozeny
zasifrovany svym uzivatelskym heslem.
> Nehlede na to, ze by to musely zacit
> zaroven podporovat vsechny klientske knihovny.
Nemusely, tem je prece jedno jestli tam zadas "jenomTvojeHeslo" nebo
"jirkovoUzivatelskyHeslo".
Teda pokud klientskou knihovnou nemyslis fbembed.dll ktery to
samozrejme umet musi,
bo v nem je AFAIK neco jako kastrovany servr bez sitovyho protokolu.
> > > K tomu jeste FB pouziva careful writes, takze opet dost casu na premysleni co kdy a kam muze tect.
> > > A to do toho netaham (shared) page cache atd.
> > Stale predpokladam ze pri sifrovani celyho xxx.fdb (narozdil od
> > ruznych sloupcovych vychytavek) to nehraje roli, souhlasis?
> Jo, ale to necekej implicitne ve FB. Tohle neni dotazene, ani "enterprise ready".
Tady se ztracim. Co neni dotazeny? To sloupcovy sifrovani? Muj navrh?
V cem?
> > Brzou bude disk a vytizeni procesoru nebude problem.
> Nektere DB jsou umistene na RAM discich a pak uz by to mohlo byt znat.
> Nicmene jiste obeti musi samozrejme ten kdo to zapne ocekavat. Jen
> jsem tim chtel rict, ze cisty vykon disku vuci CPU nemusi byt v tomto
> pripade rozhodujici.
Jo, u RAM disku to je zahul.
Casem se to nejpis taky srovna, bo rychlost procesoru stale roste vic
nez rychlost cehokoliv jinyho.
No a taky existuje
http://softwarecommunity.intel.com/isn/downloads/intelavx/AES-Instructions-Set_WP.pdf
> > Jako prvni vec zkusim tu dekompatibilizaci aby mi na to nemohl servr.
> Hlavne nikde nerikej detaily. Pac jestli ukladas *fakt* dulezity data,
> tak nekdo FB upravi stejne a je to v riiti. :)
Toho se nebojim. To by byla jen ochrana proti tomu uplne nahore
zminenymu problemu:
Naky BFU si nainstaluje muj prg a jiny hodny prg a vyleze katastrofa.
Pokud mu nekdo na jeho comp hodi upraveny FB, tak buh s nim.
> > Navic se bez toho da zit bo existuji veci jak SSL, VPN, ...
> To se da zit i bez sifrovani DB. :D Muzes to dat na sifrovanej disk.
Muzu, ale mam s tim hafo prace. Navic muj uplne nahore zmineny problem
zustava.
> Jo, to je tam jeste z predvalecny doby. A 8 fakt je to proklate malo.
> A vzhledem k tomu, ze po dratech jde heslo taky otevreny, je to dira jako prase.
To je husty ze se s tim nic nedela. Quliu tomu samozrejme musis
prepsat i klienty,
ale problem je znamy 20+ let a uz to mohlo byt aspon tak ze novy
klienti by pouzivali neco lepsiho
a servr by (volitelne) bral i predvalecnou verzi. Takhle nak to snad
ma MySql.
Jiri Cincura
> Umis si predstavit ze sdilis s nekym data, ten nekdo je vyzvani a
> presto budou bezpecny? Ja ne.
Pokud vykeca ty data, tak samozrejme ne. Jedine pokud by mela napr.
casove razitko a jejich platnost byla velmi kratka, treba nejake
koordinacni zpravy mezi systemy.
> Jediny na cem se da zapracovat je granularita.
Bingo.
> Muj navrh je uprosted. Mate spolecny.fdb a jenomTvoje.fdb, on vyzvani
> heslo k spolecny.fdb, jenomTvoje.fdb zustava v suchu.
No navrhovat, ze bude jedno heslo ke vsem DB, to snad rozumne myslici
clovek neudela.
> V cem je to horsi nez zadavat heslo co se k nicemu nepouzije?
No protoze mas jedno heslo k celymu souboru. U Embedded se user/pwd
nepouziva, pac to nedava smysl. Bezi to vsechno ve stejnym adresnim
prostoru. To je pak pseudobezpecnost, kterou se mnoho lidi ohani
jinde.
> Nemusely, tem je prece jedno jestli tam zadas "jenomTvojeHeslo" nebo
> "jirkovoUzivatelskyHeslo".
> Teda pokud klientskou knihovnou nemyslis fbembed.dll ktery to
> samozrejme umet musi,
> bo v nem je AFAIK neco jako kastrovany servr bez sitovyho protokolu.
Jo myslel jsem Embedded, resp. pripojeni k Embedded.
>> Jo, ale to necekej implicitne ve FB. Tohle neni dotazene, ani "enterprise ready".
> Tady se ztracim. Co neni dotazeny? To sloupcovy sifrovani? Muj navrh?
> V cem?
Proste slepe predpokladas a protlacujes, ze sifrovani celeho souboru
je reseni. Ale neni. Aby to mohlo byt navrzeni jako feature pro
engine, musi to umet mnohem vic, vcetne podpory spravy atp. Tohle je
dobry pro tebe. Ale FB se pouziva i v mnohem "tezsich" prostredich,
kde budou chtit mnohem pokrocilejsi fce - sloupce, predavani klicu z
klienta, <a co ja vim co jeste>.
> Muzu, ale mam s tim hafo prace. Navic muj uplne nahore zmineny problem
> zustava.
To uplne nechapu. Zasifruju soubor DB nejakym SW. Kdyz na to bude
chtit moje aplikace pristoupit, tak se zepta na heslo a soubor se ji
nejak zpristupni. Jina aplikace to nevidi bo nezna heslo a ani netusi
co s tim souborem delat.
> To je husty ze se s tim nic nedela. Quliu tomu samozrejme musis
> prepsat i klienty,
> ale problem je znamy 20+ let a uz to mohlo byt aspon tak ze novy
> klienti by pouzivali neco lepsiho
> a servr by (volitelne) bral i predvalecnou verzi. Takhle nak to snad
> ma MySql.
Server vzdy pri startu domlouva jaky protocol se pouzije, takze i
dneska podporuje starsi klienty. Od jiste verze server zpomaluje mnoho
pokusu o prihlaseni, takze brute force jde obtizneji. No a kdyz ti
nekdo slohne security2.fdb, tak je jen otazkou casu (a penez), kdy to
prolomi a ja bych radeji rovnou ukradl vlastni DB a hotovo.
Maaartin
> Bingo.
- je mnohem slozitejsi naprogramovat
- muze byt o dost pomalejsi
- ma dalsi rizika, treba prijde nekdo novy a udela novy sloupec a
zapomene ho zasifrovat
- kdyz nesifrujes indexy, tak je to dira jak prase; kdyz to delas, mas
problem pokud nepouzijes "I/O Based Encryption"
Navic si dokazu predstavit, ze kdyz sifrujes sloupce, tak to staci
treba jen jeden a to si pak udelas lehce v aplikaci.
> > Muj navrh je uprosted. Mate spolecny.fdb a jenomTvoje.fdb, on vyzvani
> > heslo k spolecny.fdb, jenomTvoje.fdb zustava v suchu.
> No navrhovat, ze bude jedno heslo ke vsem DB, to snad rozumne myslici
> clovek neudela.
No pokud je to radove lehci nez cokoliv jinyho tak jo.
Porad je to dobra ochrana proti kradezi compu.
Samozrejme ze to jde vyresit sifrovanim celyho disku.
> > V cem je to horsi nez zadavat heslo co se k nicemu nepouzije?
> No protoze mas jedno heslo k celymu souboru.
> U Embedded se user/pwd nepouziva, pac to nedava smysl.
> Bezi to vsechno ve stejnym adresnim prostoru.
> To je pak pseudobezpecnost, kterou se mnoho lidi ohani jinde.
Tys mi odpovedel na otazku kterou jsem nepolozil.
S tim ze nema smysl pouzivat autorizaci pro embedded, lze jen
souhlasit.
Sifrovani ovsem smysl ma.
> > Nemusely, tem je prece jedno jestli tam zadas "jenomTvojeHeslo" nebo "jirkovoUzivatelskyHeslo".
> > Teda pokud klientskou knihovnou nemyslis fbembed.dll ktery to samozrejme umet musi,
> > bo v nem je AFAIK neco jako kastrovany servr bez sitovyho protokolu.
> Jo myslel jsem Embedded, resp. pripojeni k Embedded.
No, to je ale jasny, kdyz pouzivas embedded, tak quli KAZDY nova
ficurce musis vymenit naky dll, bo jak jinak?
Ale kompatibilita zustane zachovana, stary embedded bude moct nadale
na nezasifrovany DB.
> Proste slepe predpokladas a protlacujes, ze sifrovani celeho souboru je reseni.
> Ale neni.
Ale je, jen to neni reseni vseho.
Resi to
- muj problem
- problem kradeze compu
- problem zlyho SYSDBA ktery neni soucasne rootem
> Aby to mohlo byt navrzeni jako feature pro engine, musi to umet mnohem vic, vcetne podpory spravy atp.
> Tohle je dobry pro tebe.
> Ale FB se pouziva i v mnohem "tezsich" prostredich, kde budou chtit mnohem pokrocilejsi fce -
> sloupce, predavani klicu z klienta, <a co ja vim co jeste>.
No chtit muzou. Sam jsi psal ze nejsou lidi.
> > Muzu, ale mam s tim hafo prace.
> > Navic muj uplne nahore zmineny problem zustava.
> To uplne nechapu. Zasifruju soubor DB nejakym SW.
To znamena, ze musim pridat instalacku toho nakyho SW (treba
truecrypt).
Prozkoumat jejich licenci.
Pridat tam nekam "Based on TrueCrypt, freely available at
http://www.truecrypt.org/".
Najit volny pismeno pro disk.
Predat heslo a pripojit disk.
Nastavit prava.
Zajistit ze disk se odpoji po skonceni programu.
Navic na instalaci truecryptu potrebujes admin prava (je v tom device
driver).
Ty jinak nepotrebujes - staci nekam nakopirovat program a vsecky DLL
od FB.
Pro Linux se to dela podobne ale jinak.
Nemluve o tom ze ten prg treba bude s necim nekompatibilni.
Nemluve o tom, ze ten uzivatel treba uz truecrypt ma a nakonfiguroval
si ho na forced automaticky odpojeni po 15 minutach,
zatimco muj prg ma bezet hodiny na pozadi.
A muj puvodni problem to stale neresi.
> To je husty ze se s tim nic nedela. Quliu tomu samozrejme musis
> prepsat i klienty,
> ale problem je znamy 20+ let a uz to mohlo byt aspon tak ze novy
> klienti by pouzivali neco lepsiho
> a servr by (volitelne) bral i predvalecnou verzi. Takhle nak to snad
> ma MySql.
> Server vzdy pri startu domlouva jaky protocol se pouzije, takze i dneska podporuje starsi klienty.
> Od jiste verze server zpomaluje mnoho pokusu o prihlaseni, takze brute force jde obtizneji.
Pokud se zpomaluje dostatecne, tak je to ok.
> No a kdyz ti nekdo slohne security2.fdb, tak je jen otazkou casu (a penez),
> kdy to prolomi
To jiste ale kdyz se pouzije password strengthening, taxe to da za
malou cenu zpomalit treba o faktor 1000.
Kdyz se pouziji poradny hesla, taxe to nevyplati.
To by ale chtelo ty poradny hesla nejdriv povolit.
Co vubec nechapu je ignorovani vsech znaku krome prvnich 8. To proste
nema smysl.
> a ja bych radeji rovnou ukradl vlastni DB a hotovo.
To jo, ale ukradenim a cracknutim security2.fdb ziskas jako bonus
hesla ktery se mozna pouzivaji i jinde.
Jasne ze se to nema, ale dela se to.
Navic muzes sledovat a modifikovat i budouci data.
Samozrejme je nejlepsi ukrast vsecko, ale treba zvladnes jen par MB
(chvilka s flashkou).
Jiri Cincura
> Mensi granularita je samozrejme lepsi ale ma i nevyhody:
Samozrejme.
> - je mnohem slozitejsi naprogramovat
To jse spis vyzva, nez nevyhoda.
> - ma dalsi rizika, treba prijde nekdo novy a udela novy sloupec a
> zapomene ho zasifrovat
Jo, pred blbosti DBA te neochrani nic.
> - kdyz nesifrujes indexy, tak je to dira jak prase; kdyz to delas, mas
> problem pokud nepouzijes "I/O Based Encryption"
> Navic si dokazu predstavit, ze kdyz sifrujes sloupce, tak to staci
> treba jen jeden a to si pak udelas lehce v aplikaci.
Jenze kdyz to delas v app, tak nemuzes pouzit plno silu (P)SQL, pac DB
netusi co je uvnitr.
> Sifrovani ovsem smysl ma.
Ovsem ne tim, ze zasifruju soubor heslem usera. To se mi pak dva
neprihlasi, resp. jeden jo a druhej ma smulu.
> No, to je ale jasny, kdyz pouzivas embedded, tak quli KAZDY nova
> ficurce musis vymenit naky dll, bo jak jinak?
> Ale kompatibilita zustane zachovana, stary embedded bude moct nadale
> na nezasifrovany DB.
Nejen, ze musis vymenit DLL, ale musi i komponenty, ktery volaji veci
z DLL vedet, ze je tam nova fce a predat ji spravny parametry.
> A muj puvodni problem to stale neresi.
Pokud to pripojis jako disk, tak ne. Ale pokud to zpristupnis jen sve
aplikaci (nevim jestli to treba ten truecrypt umi), pak nemas problem.
> Co vubec nechapu je ignorovani vsech znaku krome prvnich 8. To proste
> nema smysl.
Nema, ale je to bohuzel tak.
Maaartin
> > Sifrovani ovsem smysl ma.
> Ovsem ne tim, ze zasifruju soubor heslem usera.
> To se mi pak dva neprihlasi, resp. jeden jo a druhej ma smulu.
No to by bylo opravdu blby. Ale tak to nebude, jaxem uz psal.
Kazdy xxx.fdb muze mit vlastni heslo.
Pro embedded zada uzivatel tohle heslo namiste svyho hesla.
Pro servr se ziska odsifrovanim zaznamu z tabulky RDB$USER_KEYS v
security2.fdb pomoci hesla uzivatele.
> > No, to je ale jasny, kdyz pouzivas embedded, tak quli KAZDY nova
> > ficurce musis vymenit naky dll, bo jak jinak?
> > Ale kompatibilita zustane zachovana, stary embedded bude moct nadale
> > na nezasifrovany DB.
> Nejen, ze musis vymenit DLL, ale musi i komponenty, ktery volaji veci
> z DLL vedet, ze je tam nova fce a predat ji spravny parametry.
Ale ja tam zadnou novou fci nescu a nepotrebuju -
ta by byla mozna uzitecna pro sifrovani po sloupcich.
Pro normalni praci neni nic potreba.
Pro vytvoreni sifrovany DB a podobne se pouzije bud externi tool nebo
naky DDL prikaz -
tomu ta knihovna rozumnet nemusi.
> > A muj puvodni problem to stale neresi.
> Pokud to pripojis jako disk, tak ne. Ale pokud to zpristupnis jen sve
> aplikaci (nevim jestli to treba ten truecrypt umi), pak nemas problem.
Neumi. Ani jsem nikdy neslysel o zadnym co by to umel.
Zatim treba neodepisuj, az se do toho pustim, tak budu mit hafo dotazu.