Stiu … stiu … nu am mai scris de o tona de vreme. De cand am schimbat jobul, in sensul ca acum sunt programator … sa zicem ca am avut mult mai putin timp la dispozitie in general, deci implicit a trebuit sa tai de unde se poate … din pacate si din actiunea de a posta pe blog. Cred ca am gasit balaria aia de directie spre care ma indreptam, deci o sa mai scot din mine niste balarii tehnice.

Stateam si ma gandeam zilele acestea la o metoda de a proteja anumite aplicatii de accesul neautorizat in ceea ce priveste accesul fizic la o masina. Problema sta cam asa: un sistem securizat priveste utilizatorul ca un potential risc … deci nu este o entitate in care se pune incredere (si bine face, dar despre asta in episodul urmator). Chiar daca utilizez deja sistemul sub un cont de user dupa cum va povesteam aici, browserul, clientul de mail au master password care cripteaza parolele stocate in managerele proprii … sistemul prezinta o vulnerabilitate asupra accesului direct …

Se intampla sa vina prieteni pe la mine (din care unii evident - impart ocupatii asemanatoare), si cum nu am o masina dedicata pentru fiecare chestie in parte, sa zicem ca muzica canta de pe aceeasi masina de pe care fac development, browsing, si alte chestii. Momentan mi s-a pus pata pe cookie-uri, desi exista si alte date confidentiale care ar trebui sa ramana pe disk-urile proprii si numai acolo. Daca eu, ca detinator al sistemului … folosesc un model de securitate prin care eu nu sunt crezut fara autentificare ca superuser … de ce ar fi altii crezuti? Simplu … ei nu ar trebui sa fie, dar sunt. Browserul isi stocheaza profilul in directorul de “user data”. Chestia asta e valabila si sub *nix … deci vorbesc la cazul general, indiferent ca e vorba de /home/{user_name} sau de %systemroot%\Documents and Settings\{user_name}\Application Data (pe scurt %appdata%). Din moment ce browserul ruleaza sub un anume user … drepturile din “user data” sunt drepturile complete ale aceluiasi user. Simplu ca buna ziua. De ce nu mi-as crede proprii prieteni? Hmm … nu stiu … cred ca de cand am inceput sa citesc documentatie despre securitate … am devenit paranoic. In fine, sa continuia asupra ideei lansate.

Morala este simpla … se creeaza un utilizator cu acces limitat. Sub Windows (prin modelul prezentat in articolul anterior dedicat acestui fapt) este obligatoriu ca acesta sa aiba parola diferita de o parola nula pentru a permite utilizarea runas. Sub *nix este necesara prezenta loginului daca nu exista sudo, in caz contrar un sudo su {user_name} - ar loga un utilizator fara drept de login. Smecheria asta cu sudo am descoperit-o cand ma chinuiam sa dau drepturi de acces unui server HTTP (Apache 2) la un director SSH montat ca local prin sshfs. Solutia a fost sa montez directorul ruland comanda de mount de sub userul serverului … dupa ce in prealabil am dar acces mai larg la montare.

Dupa ce utilizatorul este creat … se muta user data-ul in directorul userului nou, se interzic drepturile de acces (citire) in ceea ce priveste fisierele utilizatorului (in cazul in care grupul/others au acces de citire la fisiere), iar aplicatia care se doreste a fi rulata protejat, se ruleaza folosind noul utilizator … astfel in momentul in care aplicatia este inchisa … datele sunt in siguranta. Ideea este simpla … punerea in aplicatie cere niste consum de taste in plus.

Apropo de paranoia care o ziceam mai sus … nu e 100% absurda. Au existat cazuri (da, la plural) cand din vina prietenilor mei, primeam acces la datele lor fara sa fac efort … mi se oferea un authentication_id (o metoda stupida de a autentifica calculand un hash obosit pentru a scuti utilizatorii unui site de actiunea de a tasta user+pass - si care ramane constant daca se schimba parola - deci algoritmul de generare este prost pentru ca nu stie de modificari, securitatea este precara datorita faptului ca un URL de acest gen este trimis in mod plain text prin retea), sau o usa de acces la chestii din sistem - si evident - nu ratam ocazia unui prank de zile mari. Motivul pentru care mi s-a pus pata pe cookie-uri care ar putea fi folosite pentru un prank la adresa proprie … motivul pentru care am varsat literele de mai sus … cu un singur catch … aplicatia nu trebuie sa ruleze ca utilzatorul respectiv in momentul in care se primesc vizite dupa modelul celui de mai sus (si chiar in general).

Disclaimer

This entry was posted on Tuesday, December 11th, 2007 at 7:04 pm and is filed under Linux, Mac OS X, Tech, Windows. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.