Obyčejně nejsou novinky zajímavé, dokud nejsou použitelné, ale v tomhle konkrétním případě je potřeba se trochu víc podívat na to, co vlastně Big Sur přinesl pro koncové uživatele a popřemýšlet, kdo ve skutečnosti stojí za tímto globálním spiknutím. Pokud mi některé věci nedají spát, většinou nespím a nemůže za to jen paranoia, Zuzana, poblouznění, nebo cizí sukuby v ulicích a panický strach z policie.
Co je teda tak děsivé, že se musím vyjádřit k novému systému, ačkoliv se to běžně neděje? S Big Surem a potažmo novou architekturou, resp. celým hardwarovým ekosystémem protkaným secure enklávami, přišly do života v první řadě nové bezpečnostní mechanismy. Asi nejvíc patrné to bude rozšířením SIPu o kryptografické ověřování systémových APFS oddílů a pak hlavně jednou velmi divokou novinkou, která s tím tak trochu souvisí, praktickým zákazem jaderných rozšíření. Obojímu by asi nebylo co vytknout, minimálně co se dobrých úmyslů týče, to rozhodně. Zmiňovaný SIP už kdysi vyvolával obavy o to, zda neskončíme s rootless prostředím, ale nakonec se to osvědčilo jako docela dobrá věc, která skutečně v mnoha případech mohla Mac ochránit před výbuchem. Stále bylo totiž relativně dobře možné SIP snadno vypnout, provést vědomě změny a zase ho zapnout. Nyní SIP přinesl to ověřování, čili bez explicitního vynucení neověřování se sice změny dají provést, bohužel se ale nedají běžně používat. K druhému jmenovanému také není na první pohled co vytknout, přeci nechceme, aby nějaký špatně napsaný kext sestřelil jádro zrovna ve chvíli, kdy to nejvíc potřebujeme. A protože jsou k těmto účelům speciálně vytvořené nové frameworky, které by měly zajistit totožné, ale bezpečnější chování systému, není potřeba se znepokojovat. Nebo ano?
No je to tak, hypoteticky není, ovšem pouze za předpokladu, že to nějaký liberál nezačne zneužívat, jak se v tuhle chvíli bohužel stalo. Když si jako příklad vezmeme v úvahu třeba USB-C, tak to je teoreticky taky úplně v pohodě. Teoreticky. Teoreticky funguje i komunismus. Přesto není možné jednoduše zabránit tomu, že si nějaký výrobce řekne, že pokud nebude USB-C zařízení, třeba obyčejný kabel, vyloženě podepsaný jeho certifikátem, počítač s ním zcela odmítne komunikovat. No a to, co se stalo teď, je dost podobné, možná jen o značně větší část děsivější.
Už nějakou dobu se díky jaderným rozšířením svět těšil všemožným ALF a VPN, které fungovaly naprosto skvěle a člověk měl díky tomu svůj počítač pod kontrolou a věděl, že nedochází na lámání chleba. Síťová rozšíření mohla totiž přímo do firewallu jádra, bylo tedy hypoteticky možné udělat cokoliv, co umí téměř všemocný PF, ale bez nutnosti dělat věci kostrbatě. Současná rozšíření tohle možná umožňují také, ale z nějakého zákeřného důvodu byl vytvořen speciální a nezdokumentovaný seznam 56 interních programů a aplikací, které mají z globálního zpracování síťovými filtry udělenou výjimku – ContentFilterExclusionList. Co to přesně znamená? Že všechny programy uvedené na tomto seznamu nejen, že nebudou respektovat nastavení filtrů, ale budou moci také svá spojení téměř libovolně poskytovat externím procesům, které o ně prostě zažádají. No a pak že jsme šílenci my. Definice seznamu je následovná:
<!-- /System/Library/Frameworks/NetworkExtension.framework/Resources/Info.plist --> ... <key>ContentFilterExclusionList</key> <array> <string>/usr/libexec/findmydeviced</string> <string>/usr/libexec/mobileassetd</string> <string>/System/Library/CoreServices/Software Update.app/Contents/Resources/softwareupdated</string> <string>/System/Library/PrivateFrameworks/AssistantServices.framework/Versions/A/Support/assistantd</string> <string>/System/Library/PrivateFrameworks/CoreParsec.framework/parsecd</string> <string>/System/Library/PrivateFrameworks/AppStoreDaemon.framework/Support/appstored</string> <string>/System/Library/PrivateFrameworks/AppStoreDaemon.framework/Support/appstoreagent</string> <string>/System/Applications/App Store.app/Contents/MacOS/App Store</string> <string>/System/Library/PrivateFrameworks/ApplePushService.framework/apsd</string> <string>/System/Library/PrivateFrameworks/CloudKitDaemon.framework/Support/cloudd</string> <string>/System/Library/PrivateFrameworks/IDS.framework/identityservicesd.app/Contents/MacOS/identityservicesd</string> <string>/System/Library/PrivateFrameworks/IMCore.framework/imagent.app/Contents/MacOS/imagent</string> <string>/System/Library/PrivateFrameworks/IDSFoundation.framework/IDSRemoteURLConnectionAgent.app/Contents/MacOS/IDSRemoteURLConnectionAgent</string> <string>/System/Library/PrivateFrameworks/IMFoundation.framework/XPCServices/IMRemoteURLConnectionAgent.xpc/Contents/MacOS/IMRemoteURLConnectionAgent</string> <string>/System/Library/PrivateFrameworks/PassKitCore.framework/passd</string> <string>/usr/libexec/mdmclient</string> <string>/usr/libexec/teslad</string> <string>/System/Library/PrivateFrameworks/GeoServices.framework/Versions/A/XPCServices/com.apple.geod.xpc/Contents/MacOS/com.apple.geod</string> <string>/System/Library/PrivateFrameworks/SyncedDefaults.framework/Support/syncdefaultsd</string> <string>/System/Library/CoreServices/mapspushd</string> <string>/System/Library/TextInput/kbd</string> <string>/System/Library/PrivateFrameworks/MapsSuggestions.framework/MapsSuggestions</string> <string>/usr/sbin/securityd</string> <string>/usr/libexec/locationd</string> <string>/System/Library/PrivateFrameworks/AuthKit.framework/Versions/A/Support/akd</string> <string>/System/Library/Frameworks/Accounts.framework/Versions/A/Support/accountsd</string> <string>/usr/libexec/tailspind</string> <string>/System/Library/CoreServices/cloudpaird</string> <string>/usr/libexec/fmfd</string> <string>/System/Library/PrivateFrameworks/HomeKitDaemon.framework/Support/homed</string> <string>/System/Library/PrivateFrameworks/FamilyNotification.framework/FamilyNotification</string> <string>/System/Library/PrivateFrameworks/AssetCacheServices.framework/Versions/A/XPCServices/AssetCacheLocatorService.xpc/Contents/MacOS/AssetCacheLocatorService</string> <string>/System/Library/PrivateFrameworks/MusicLibrary.framework/MusicLibrary</string> <string>/System/Library/PrivateFrameworks/DistributedEvaluation.framework/Versions/A/XPCServices/com.apple.siri-distributed-evaluation.xpc/Contents/MacOS/com.apple.siri-distributed-evaluation</string> <string>/System/Library/PrivateFrameworks/FamilyCircle.framework/Versions/A/Resources/familycircled</string> <string>/System/Library/PrivateFrameworks/MediaStream.framework/MediaStream</string> <string>/usr/libexec/swcd</string> <string>/usr/libexec/rtcreportingd</string> <string>/usr/libexec/networkserviceproxy</string> <string>/System/Library/PrivateFrameworks/MapsSupport.framework/MapsSupport</string> <string>/System/Library/Frameworks/CoreTelephony.framework/Support/CommCenter</string> <string>/usr/libexec/mobileactivationd</string> <string>/usr/libexec/trustd</string> <string>/System/Library/PrivateFrameworks/ProtectedCloudStorage.framework/Helpers/ProtectedCloudKeySyncing</string> <string>/usr/libexec/siriknowledged</string> <string>/usr/libexec/coreduetd</string> <string>/usr/libexec/timed</string> <string>com.apple.facetime</string> <string>/System/Library/PrivateFrameworks/CommerceKit.framework/Resources/commerced</string> <string>/System/Library/PrivateFrameworks/CommerceKit.framework/Versions/A/Resources/commerce</string> <string>/usr/libexec/secd</string> <string>/System/Library/PrivateFrameworks/IMTransferServices.framework/IMTransferAgent.app/Contents/MacOS/IMTransferAgent</string> <string>/System/Library/PrivateFrameworks/CoreSpeech.framework/corespeechd</string> <string>/System/Library/CoreServices/mapspushd</string> <string>/System/Library/PrivateFrameworks/CoreLSKD.framework/Versions/A/lskdd</string> <string>/usr/libexec/diagnosticd</string> </array> ...
Jaký je tedy praktický dopad? Velmi jednoduše řečeno není možné programům uvedeným na seznamu usměrnit způsob síťové komunikace. V první řadě se to může týkat třeba oblíbených nástrojů, jakými jsou Little Snitch nebo TripMode. Oboje mají svoje opodstatnění, to nechávám na posouzení komukoliv, přesto jejich hlavní devizou je za určitých podmínek na aplikační úrovni jednotlivým programům znemožnit či umožnit přístup k síti; kdo nerozumí výhodám, pak jeden super tip na použití je zakázat mailovým klientům jakoukoliv síťovou komunikaci kromě poštovních služeb (SMTP, IMAP, MAPI), čímž se nebude stahovat – byť jen z náhodné nepozornosti – žádný webový obsah v HTML zprávách (které by taky měly být zcela zakázány, že, protože plaintext rules). Za další se tím třeba znemožňuje měření datových toků softwarových updatů a tak dále.
A může být hůře. On-demand VPN určené pro zabezpečení jsou většinou nastavené takovým způsobem, že veškerý síťový provoz z počítače routují přes svoje interfacy a až někde na druhé straně se teprve externí adresy hlásí koncovým bodům. Jinými slovy, počítač je připojen na nějaké síti, zřejmě od ní dostal přes DHCP interní adresu, nicméně neměl by se nijak hlásit a z pohledu sítě by měl generovat pouze jediné spojení skrze jediný port, a to ještě ke všemu šifrovaně. A basta. Bohužel v tomto režimu se interní programy dostanou pouze do systémem určené sítě, a tedy provoz nebude routovaný přes VPN. Počítač již nebude maskovaný a bude možné na základě jeho chování v síti zcela pasivním způsobem sledovat chování jeho uživatele.
Stále nic? Pak byl zajímavý příspěvek, kde @patrickwardle demonstruje, jak může zcela jednoduše neprivilegovaným a nikým neověřeným skriptem požádat povolenou službu, aby za něj odevzdala data ku kamsi a nikoho se na nic neptala. Jsme tedy svědky globálního spiknutí, kde se v US nejen falšují volby, ale zcela otevřeně se loupí data uživatelů za cílem je zotročit? Vznikl přesně podle tohoto ďábelského plánu PES za účelem zakázat v Evropě Vánoce? Není tohle už čas na nepokoje?
Protože se v tom miluji vrtat, pokusil jsem se tedy tento seznam vyřadit ze hry a otestovat, zda nějakým způsobem ještě někde něco neteče. Ono nejspíše teče, ale ať na to přijdou raději ostatní, tohle musí být zkrátka jen špička ledovce, která je každému jen snadno viditelná a dostupná. Big Sur, ačkoliv to Davídek asi pořád nechápe, nemám na žádném skutečném stroji. Běží mi pod VM, na něm je nový Little Snitch 5 a ještě nějaké další úpravy pro jiná testování. Na to, že to celé teď dělám vzdáleně, to kupodivu není zas tak hrozné, jak by si podle mého vrčení možná králíková víla mohla myslet.
Prvním úkolem je rozvrhnout si, čeho je tedy potřeba dostáhnout – výše uvedený výňatek property listu ve svém klíči ContentFilterExclusionList definuje pole cest k vyňatým programům. Možná než to celé rozbít a smazat bude lepší ponechat tam seznam definovaný, ale jeho pole zcela prázdné. Takže nasnadě je prostě všechno od jeho začátku až po konec jednoduše XML-zakomentovat. Proč ne. No jenže ouha, žejo, SIP nám nedovolí provádět úpravy na systémovém svazku, dokud to nevypneme. Vypnutí v Recovery režimu je poměrně snadné, ale je potřeba si ještě taky uvědomit, že svazek je zaprvé kryptograficky podepsaný... a za druhé, že díky novým schopnostem APFS reziduje na samostatném snapshotu, takže jakákoliv úprava se stejně neprojeví, pokud nevytvoříme nový snapshot. Postup je ale přitom docela jednoduchý, jen to musí včas docvaknout – po vypnutí SIP to bootneme normálně a pak je potřeba se podívat, kde je vlastně přimountovaný /
. Bez ohledu na jeho konkrétní snapshot se musí nejprve hrubý APFS svazek připojit na nějaké místo (v tomhle případě třeba ~/zlo
) a následně, a to je zajímavé, modernizovaným způsobem snapshotovat a požehnat. Utilitka bless v tomhle ohledu utrpěla taky, zdá se, několik změn. Více viz postup.
# Recovery: root@Eidas-Mac ~ # csrutil disable root@Eidas-Mac ~ # csrutil authenticated-root disable # Normální boot: eida@Eidas-Mac ~ % mount /dev/disk1s5s1 on / (apfs, sealed, local, read-only, journaled) devfs on /dev (devfs, local, nobrowse) /dev/disk1s4 on /System/Volumes/VM (apfs, local, noexec, journaled, noatime, nobrowse) /dev/disk1s2 on /System/Volumes/Preboot (apfs, local, journaled, nobrowse) /dev/disk1s6 on /System/Volumes/Update (apfs, local, journaled, nobrowse) /dev/disk1s1 on /System/Volumes/Data (apfs, local, journaled, nobrowse) map auto_home on /System/Volumes/Data/home (autofs, automounted, nobrowse) .host:/VMware Shared Folders on /Volumes/VMware Shared Folders (vmhgfs) /dev/disk2s3 on /Volumes/Install macOS Big Sur (hfs, local, nodev, nosuid, read-only, noowners) eida@Eidas-Mac ~ % mkdir zlo eida@Eidas-Mac ~ % sudo mount -o nobrowse -t apfs /dev/disk1s5 zlo/ Password: eida@Eidas-Mac ~ % sudo nano zlo/System/Library/Frameworks/NetworkExtensions.framework/Resources/Info.plist eida@Eidas-Mac ~ % sudo bless --folder zlo/System/Library/CoreServices --bootefi --create-snapshot
Po vytvoření požehnaného snapshotu by už mělo stačit rebootovat a přesvědčit se, zda se změna v property listu síťových rozšíření, tedy vynulování seznamu výjimek, skutečně promítla. Pakliže jo, tak tady třeba díky testování pomocí Little Snitch postačí vypnout sady pravidel pro Apple, sady pravidel pro iCloud služby a ještě explicitně třeba zakázat App Store pro demonstraci. K mému velkému překvapení skutečně App Store nenaběhlo a Little Snitch provedl správné odchycení procesů a zakázal je. Tím pádem by se to mělo dát i v pohodě routovat VPNkou, zdá se, ale nevyzkoušeno.
-
Ajaj, seznam vyloučených programů
-
App Store nerespekute zákaz...
-
Po opravě už zákaz respektuje a nenačte nic
Stinnou stránkou procesu ale zůstala pachuť toho, že jsme nyní vypnuli SIP a především povolili bootováni z nepodepsaných oddílů. Ono to asi úplně u osobního počítače nevadí, ale může se stát, že to nějaká další zákeřnost pohotově zneužije a bude. Druhou, bohužel o dost horší a více stinnou stránkou je pak fakt, že jakákoliv budoucí aktualizace systému vytvoří nový podepsaný snapshot a s velkou pravděpodobností provedené změny zatratí. I když třeba ne, nevím, taky to nebylo vyzkoušeno.
Možná pozitivní stránkou věci by pak mohlo být, že se tímhle úmyslným problémem zabývá docela dost lidí a zlobí se na Apple, že nepokrytě podporuje hnus, levárny a darebáctví. Přehodnocení z featury na zločin, za který se bude někdo zodpovídat, se zřejmě konat nebude, ale mluvit o tom už jako o návrhové chybě, nebo třebas o security concern, je asi v tuhle chvíli za tím to, za co můžeme být vděční.
In the light of the recent public discussions that this topic has triggered we are extremely confident that Apple stands by their word to give users control over their information and will therefore eliminate this kind of whitelisting in a future macOS update. – Objective Development jsou optimisti
Takže dokud tohle nebude uvedené na pravou míru a seznam výjimek permanentně zrušen, nikomu nedoporučuji Big Sur používat, protože není bezpečný. Za mě tedy dnes pouze nula hvězdiček z pěti a časem, možná, uvidíme – to abychom všude nemuseli chodit s vlasním hardwarovým aparátem navíc, na kterém bude už kompletně nastavená síť jen pro použití moderního Macu. Bohužel je tohle černá skrvna na všem, co Steve vytvořil, tenhle síťový big surrealismus zřejmě už navždycky změní pohled na Apple, kdykoliv bude říkat, že je bezpečnost a soukromí jejich největší důležitostí.