Přijde mi, že snažit se zabezpečit uživatelova data před ním samotným je ztracený boj, zvlášť pokud je to administrátor. A je to tak dobře. Opak by znamenal, že uživatel nemá kontrolu nad vlastním strojem. Takže celý tento threat model je takový podivný. Pokud jsou ta data příliš citlivá, tak je buď nesmím ukládat, nebo nesmím pouštět nedůvěryhodný kód s privilegii svého účtu...
Jiný příklad podobného boje s větrnými mlýny jsou různé čím dál zoufalejší pokusy o ochranu před změnou asociací souborů.
17. 4. 2026, 19:39 editováno autorem komentáře
"Přijde mi, že snažit se zabezpečit uživatelova data před ním samotným je ztracený boj, zvlášť pokud je to administrátor.
"
Jak to myslíte? Sice souhlasím, že uživatel by měl mít nad svým strojem kontrolu, ale pokud si jako uživatel pustím game.exe, tak asi úplně nezamýšlím, aby mi to skenovalo disk a hledalo krypto peněženky a ssh klíče...
"nebo nesmím pouštět nedůvěryhodný kód s privilegii svého účtu...
"
Souhlasím. Asi by bylo fajn, kdyby i desktopový OS měly lepší sandboxing.
No problém je, že nedílnou součástí kontroly je možnost ji delegovat, třeba na nějaký kus softwaru. Protože být nucen něco dělat ručně je taky forma omezení zvenku. (A třeba zrovna u těch asociací mi to jako správci většího množství počítačů extrémně komplikuje život a přidělává práci.)
A ano, pak je tedy otázka, jak definovat, kterému kusu softwaru chci delegovat kolik práv. Na desktopech je desetiletími zavedený koncept, že program, který spustím pod svým účtem z definice může dělat cokoli, co můžu já. Jestli je to ideální, je samozřejmě jiná diskuze, a možná by nějaký jemnější bezpečnostní model / sandboxing byl fajn. Ale udělat to čistě by vyžadovalo skutečně nový bezpečnostní model. Tyto podivné nesystematické ohýbávky, kde systém něco šifruje sám před sebou a přitom jiná část má klíč, pak nějaká jiná část monitoruje, že na něj nehrabete, atp., jsou prostě příliš krkolomné a křehké. Prostě model "rovnák na ohýbák"....
17. 4. 2026, 19:57 editováno autorem komentáře
Zabezpečit data před uživatelem nejde (ačkoliv jak řekli jiní, neznamená to, že by jakýkoliv proces měl nutně mít přístup k jakýmkoliv datům). Lze tomu ovšem jít naproti tím, že třeba v systému zbytečně neběží, co nemá (recall) a že tam nejsou citlivá data, která jsou nepotřebná (to, co sbírá recall), pokud uživatel explicitně nerozhodne jinak.
Tohle je situace úplně stejná, jako když ti do rozvědky pronikne na vysokou funkci krtek. Může ke všemu, k čemu mu z titulu funkce přistupovat přísluší, a často i k lecčemu, k čemu mu to nepřísluší, ale kolegové mu vyjdou vstříc, protože je to přece spolehlivej kolega a navíc kámoš, kterýmu není blbý zatáhnout po úředních hodinách rundu.
Zabezpečitelný je to jedině tak, že se budeš maximálně snažit, aby se tam krtek v první řadě vůbec nedostal (tzn kontrola kódu co uživatel chce spouštět, defaultně zákaz přístupu a pro dotyčnou aplikaci to uživatel nebo ještě líp admin organizační jednotky musí explicitně povolit, apod.); i tak ale stejně musíš počítat s tím, že se tam nakonec nějak dostane, už jen s ohledem na to, že ho tam může strčit admin, a hlídáním anomálií (nárůst přístupů, objemy čtení, jestli vzorec přístupů dává smysl v kontextu normálního použití, přenosy na adresy mimo whitelist, apod.). Ovšem napřed musí někdo nominální chování definovat.
A pro účely auditu a pitvy (post-mortem analýzy) eventuálního útoku zapisovat, k čemu jakej proces kdy přistupoval.
A ideálně by to nemělo umožnit zametení stop.
Což má všechno docela značný dopady na výkon, na komplexitu kódu, a na možnost vnesení chyb a následně dalších zranitelností, na který se dá zaútočit.
Sečteno a podtrženo: dokážu si představit že to spoustě lidí pomáhá (Původní Timeline byla bezva věc, a zvyknul jsem si na ni už na prastarý Xperii X10 miniPro), ale z hlediska bezpečnosti dat a možnosti krádeže identity je to noční můra.
20. 4. 2026, 07:52 editováno autorem komentáře