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
S velkou částí souhlasím, ale mám jednu poznámku: To šifrování může mít význam, když nemáme šifrování FS, a pokud je klíč odvozen od hesla. Nevím, jak je to na Windows, na Linuxu třeba gnome-keyring heslo využívá. Stále to není ideální, neřeší to moc leaky třeba do swapu, ale lepší než nic.
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
"uživatel nemá kontrolu nad vlastním strojem" - v tom dosáhl mistrovství MacOS. Tam si ani jako root neuprdneš, nemůžeš manipulovat se system. oddílem.
Vola sa to SIP a da sa to vypnut. Podobne, ako ked linuxe namountujem / ako read-only, tak ani root do neho nemoze sahat. Ked ho remountnem s read-write, tak moze. (A ked na linuxe takto porusim hashe dm-verity, tak je to tiez moj problem).
Spis to je neco jineho.
Typicky to brani provozu toolu, ktere potrebuji eskalovat opravneni, napr. ruzne firmware updatery, ktere vyrobce jednou stvoril a ocekava se ze budou fungovat - nuz nebudou - musite prebootovat do jakehosi "unsafe" modu, kde si provedete ten ukon, a pak zas zpet.
Working as intended ;-) Systemovy volume je od verze 10.15 (2019) read only. Aktualizace udela RW snapshot (APFS je CoW a snapshoty umi) udela zmeny a pri rebootu zkontroluje checksum a prepne je. Je to popravde docel elegantni, neco jako immutable linux distro akorat BFU friendly :)
To se ti dobre rekne, ale kopec tech dat proste potrebujes a/nebo chces.
A mezi totalne bezpecna a totalne nebezpecna je docela velky prostor, kde se muzes pohybovat.
Tak spíš je otázka, kdo vlastně ten recall chtěl? Lepit díry poté, co nasílu byl koncept protlačen je komické.
My ze oboru to třeba nechápeme, ale když jsem se o tom bavil s lidmi, kteří ten počítač používají jen k práci, tak někteří byli funkcionalitou recallu nadšení, a říkali, že to je skvělý nápad, že o tom vůbec nevěděli.