Kontrollera alla Mac-apps signatur och notarisering från terminalen

Gatekeeper kör den här kontrollen automatiskt första gången du öppnar en nedladdad app, och för det mesta ser du aldrig detaljerna – en dialogruta visas, du klickar dig igenom den, klar. Det här labbet handlar om att se vad Gatekeeper såg: vilken utvecklare som signerade appen, om den signaturen är intakt, om Apples notarietjänst kontrollerade den och vad den är tillåten att göra när den körs. Varje kommando här levereras med Xcodes kommandoradsverktyg (xcode-select --install om du inte har dem ännu), och var och en av dem är skrivskyddad - du inspekterar, inte ändrar, appen.

Själva signaturen: codesign -dvvv

codesign är Apples verktyg för att skapa och inspektera kodsignaturer. -d-flaggan visar information om den signerade koden vid en sökväg, och enligt dess man-sida, "Ökande nivåer av utförlighet ger mer utdata" - så -dvvv (display, tre nivåer av utförlig) ger dig hela bilden med ett kommando:

$ codesign -dvvv /Applications/Example.app
# example output, trimmed to the fields that matter
Executable=/Applications/Example.app/Contents/MacOS/Example
Identifier=com.example.app
Format=app bundle with Mach-O universal (x86_64 arm64)
CodeDirectory v=20500 size=... flags=0x10000(runtime) hashes=...
Signature size=4741
Authority=Developer ID Application: Example Software LLC (ABCDE12345)
Authority=Developer ID Certification Authority
Authority=Apple Root CA
Team Identifier=ABCDE12345
Runtime Version=14.0.0

Fyra fält att läsa varje gång. Authority är certifikatkedjan: en normal, extern app ska sluta på Apple Root CA genom Developer ID Certification Authority, med den översta raden som namnger utvecklaren. Team Identifier är Apples ID på tio tecken för utvecklarkontot – värdet att jämföra mellan appar som du tror kommer från samma företag, eftersom det inte ändras mellan deras utgåvor. flags=0x10000(runtime) betyder att den härdade körtiden är aktiverad, en uppsättning ytterligare begränsningar (som att motstå kodinjektion i processen) som Apple kräver för attestering. Och frånvaron av någon Authority-linje alls – bara Signature=adhoc – betyder att appen är osignerad eller självsignerad utan någon som helst kedja till Apple.

Matchar signaturen fortfarande filerna: --verify --deep --strict

En signatur är ett löfte om en specifik uppsättning byte vid undertecknandet. --verify kontrollerar om det löftet fortfarande håller - enligt man-sidan bekräftar det "att koden på dessa sökvägar är signerad, att signaturen är giltig och att alla förseglade komponenter är oförändrade." Två extra flaggor är viktiga för ett app-paket, som är en katalog full av kapslade resurser, ramverk och hjälpprogram, inte en enda fil:

$ codesign --verify --deep --strict --verbose=2 /Applications/Example.app
/Applications/Example.app: valid on disk
/Applications/Example.app: satisfies its Designated Requirement

--deep är viktiga eftersom, enligt man-sidan, verifiering av kapslat innehåll är som standard "begränsad till en ytlig undersökning som kanske inte upptäcker ändringar i den kapslade koden" — djupläget verifierar rekursivt varje inbäddat ramverk och hjälpverktyg, inte bara det yttre paketet. --strict lägger till extra kontroller som Apple anser vara tillräckligt viktiga för att inte vara på som standard, inklusive att alla symboliska länkar inuti paketet "pekar[er] på förseglade filer inuti dess paket", och avvisar en som pekar utanför appen eller till något oförseglat – ett känt knep för att smuggla en osignerad nyttolast till en annars legitimt signerad bunt. Om någon av kontrollen misslyckas kommer du att se code failed to satisfy specified code requirement eller en anteckning som namnger exakt vilket kapslat objekt som inte matchar det som ursprungligen förseglades - läs den raden, den namnger filen.

Läser rättigheterna

Rättigheter är de specifika behörigheter som en apps signatur ger den – kameraåtkomst, möjligheten att nå nätverket utan sandlådor, inaktivera biblioteksvalidering och så vidare. codesign -d --entitlements - extraherar dem; per man-sidan, "Inbäddade rättigheter kommer att extraheras på samma sätt och skrivas till" den givna sökvägen, och - betyder standardutdata:

$ codesign -d --entitlements - /Applications/Example.app
# example output, trimmed
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
<key>com.apple.security.network.client</key>
<true/>
<key>com.apple.security.device.camera</key>
<true/>

De flesta rättigheterna är omärkliga och matchar vad appen uppenbarligen behöver - en videosamtalsapp som begär kameraåtkomst är inte ett fynd. Den som är värd att pausa på är disable-library-validation: det betyder att appen kommer att ladda koden utanför sitt eget signerade paket, vilket är ett normalt behov av viss plugin-baserad programvara och en bredare dörr än de flesta appar kräver. Det är en detalj att notera, inte en automatisk röd flagga, och det är precis den typ av detalj som du inte kan se utan att fråga.

Har Apples notarietjänst faktiskt kontrollerat det: spctl och häftapparat

En giltig signatur bevisar bara att en app inte har ändrats sedan en utvecklare signerade den - den säger ingenting om huruvida Apple har tittat på den. Det är vad notarisering lägger till. Apples egen dokumentation beskriver den automatiska notarietjänsten som att skanna "din programvara efter skadliga komponenter, kontrollera om det finns problem med kodsignering och snabbt returnera resultaten till dig." När det går, "genererar notarius publicus en biljett som du kan häfta till din programvara; notarius publicus även den biljetten online där Gatekeeper kan hitta den."

spctl --assess är det praktiska sättet att fråga Gatekeepers egen policymotor om dess bedömning snarare än att sluta sig till det själv. Enligt sin man-sida, --assess "utför[s] en bedömning av de givna filerna," och -v / --verbose, upprepas för mer detaljer, beskrivs helt enkelt som att begära "mer utförlig utdata":

$ spctl --assess -vv /Applications/Example.app
/Applications/Example.app: accepted
source=Notarized Developer ID

source=Notarized Developer ID är resultatet du vill se — det betyder att Gatekeeper hittade en giltig utvecklar-ID-signatur och en notariseringsärende, oavsett om den biljetten är häftad i appen eller hittades online. Ett resultat av source=Unnotarized Developer ID betyder att appen är signerad men Apple har inte (eller ännu inte) attesterat den, och en platt rejected betyder att Gatekeeper skulle blockera den från att starta i sin standardkonfiguration.

För att kontrollera häften specifikt letar xcrun stapler validate efter biljetten som är fysiskt kopplad till appen istället för att be Gatekeeper att leta upp den online – användbart för att bekräfta att en app fortfarande kommer att bedöma korrekt utan internetanslutning alls:

$ xcrun stapler validate /Applications/Example.app
Processing: /Applications/Example.app
The validate action worked!

Karantänflaggan: varifrån den första kontrollen kommer

Apples plattformssäkerhetsguide förklarar att "Gatekeeper spårar även härkomsten av filer skrivna av nedladdad programvara" och "begär användargodkännande innan nedladdad programvara öppnas för första gången." Mekanismen bakom det är ett utökat attribut, com.apple.quarantine, som Safari, Mail och andra appar kopplar till allt de sparar från nätverket. xattr -l listar det, och enligt man-sidan gör det här alternativet "att både attributnamnen och motsvarande värden visas":

$ xattr -l ~/Downloads/Example.dmg
com.apple.quarantine: 0081;65e1a2b3;Safari;

Ingen utdata alls betyder att filen inte har någon karantänflagga - antingen skapades den lokalt, kom via en sökväg som inte anger attributet (vissa arkivverktyg och pakethanterare hoppar över det), eller så togs flaggan bort manuellt med xattr -d com.apple.quarantine. Det sista fallet är värt att veta om av en annan anledning: det är ett dokumenterat sätt som människor kringgår Gatekeepers första kontroll helt, på filer de litar på eller tror att de litar på, och det är värt att överväga snarare än att klistra in från en obekant uppsättning terminalinstruktioner.

En fungerade jämförelse: två appar som gör anspråk på samma utvecklare

Ett konkret sätt att använda allt detta tillsammans: säg att du har två exemplar av en app som båda påstår sig vara från samma företag, en från utvecklarens egen sida och en från en länk som någon skickade till dig. Kör codesign -dvvv på båda och jämför Team Identifier-raden — det är en sträng på tio tecken som är knuten till ett specifikt Apple Developer-konto, och till skillnad från ett visningsnamn eller en paketidentifierare är det inte något som en andra part tillfälligt kan reproducera utan tillgång till kontots signeringscertifikat. Om de två kopiorna visar olika teamidentifierare, tittar du inte på två versioner av samma app; du tittar på två olika undertecknare, varav en inte är den som nedladdningen gjorde anspråk på. Följ det med spctl --assess -vv på den misstänkta kopian - en felaktig eller frånvarande notariseringskälla på kopian som påstår sig vara identisk med ett attesterat original är bekräftelsen, inte bara en ledtråd.

Läser hela bilden och de faktiska röda flaggorna

• Ingen Authority kedja alls, eller en kedja som inte slutar i Apple Root CA – appen har ingen ansvarsfull utvecklaridentitet bakom sig.
• codesign --verify misslyckas, särskilt med ett meddelande som namnger en specifik kapslad fil — något inuti paketet ändrades efter att det signerades.
• spctl --assess returnerar rejected, eller så stämmer inte teamidentifieraren i codesign -dvvv med den utvecklare du förväntar dig för den produkten.
• En karantänflagga som var tydligt avskalad på en fil som du inte laddat ner själv, eller som kom via en ovanlig kanal (ett skript, en e-postbilaga som döpts om för att se ut som något annat).
• Behörigheter som är vidöppna – full diskåtkomst, inaktiverad biblioteksvalidering, obegränsad nätverksåtkomst – på en app vars angivna syfte inte uppenbarligen behöver dem.

Ingen av dessa kontroller tittar på vad appen faktiskt gör när den väl är igång och ansluten till nätverket - det är en annan typ av fråga, besvarad genom att titta på dess trafik snarare än dess signatur. En ren signatur och en giltig notariseringsbiljett är ett riktigt, meningsfullt golv: de säger att Apple har sett denna exakta uppsättning byte och inte hittat några kodsigneringsproblem vid tidpunkten för kontrollen. De är början på att lita på en app, inte slutet på den.

Var FireAI och HisnLabs kommer in

A clean signature and a stapled ticket say an app hasn’t been tampered with since Apple checked it — they say nothing about what it connects to afterward, which is the question FireAI’s per-app rules and on-device review are built to keep answering, signature by signature, connection by connection.

FireAI är HisnLabs eget verktyg: en AI-brandvägg som körs direkt på din Mac. Den visar varje anslutning dina appar gör, på klarspråk, och låter dig avgöra vad som lämnar din Mac — AI:n körs lokalt, så din trafik skickas aldrig till oss eller någon annan. HisnLabs säkerhetsforskningsteam är de som håller de bedömningarna tillförlitliga: de katalogiserar vilka domäner som är vanlig telemetri och vilka som är en riktig tjänst, spårar land och nätverk bakom en anslutning och tränar den lokala modellen (Autopilot-funktionen) på verkliga trafikmönster — utan att något av det lämnar din Mac.

Du kan läsa om de tekniska besluten bakom, eller prova FireAI i 17 dagar, på FireAI, från HisnLabs.