macOS की Privacy & Security सेटिंग्स पर भरोसा क्यों नहीं किया जा सकता

• यह पुष्टि हुई है कि macOS की Privacy & Security सेटिंग्स वास्तविक access permission की स्थिति को सही तरीके से नहीं दिखातीं
• Documents फ़ोल्डर का access blocked होने पर भी Insent ऐप अब भी फ़ाइलें पढ़ सकता है
• जब उपयोगकर्ता फ़ोल्डर को सीधे चुनता है, तो TCC system इसे intentional access मानकर restrictions हटा देता है
• settings screen में blocked दिखने के बावजूद, वास्तव में sandbox restrictions हट जाती हैं और access जारी रहता है
• access को पूरी तरह block करने के लिए terminal command और restart की ज़रूरत पड़ती है, जिससे उपयोगकर्ता के control के खोने का जोखिम हो सकता है

---

macOS Privacy & Security सेटिंग्स की विश्वसनीयता की समस्या

• ऐसे मामले की पुष्टि हुई है जहाँ macOS Privacy & Security सेटिंग्स वास्तविक access permission की स्थिति को सही तरीके से reflect नहीं करतीं
  • Insent नाम के एक सरल ऐप का उपयोग करके यह पाया गया कि Documents फ़ोल्डर access permission settings में blocked होने पर भी वास्तविक access संभव है
  • यह समस्या macOS 13.5 और उससे ऊपर के versions में भी उसी तरह reproduce की जा सकती है

• Insent ऐप कैसे काम करता है

  • Open by consent बटन उपयोगकर्ता की सहमति के बाद Documents फ़ोल्डर के भीतर किसी text file को खोलकर दिखाता है
  • Open from folder बटन में, यदि उपयोगकर्ता फ़ोल्डर को सीधे चुनता है, तो उसके भीतर की फ़ाइलें खोली और दिखाई जाती हैं
  • दूसरे मामले में उपयोगकर्ता की intent को access permission माना जाता है, इसलिए TCC(Transparency, Consent, and Control) system बिना अलग consent के access की अनुमति दे देता है

• परीक्षण प्रक्रिया और परिणाम

  • पहले Documents access की अनुमति देने के बाद यह पुष्टि की गई कि Insent सामान्य रूप से फ़ाइल पढ़ सकता है
  • उसके बाद Privacy & Security settings में Insent का Documents access disable करने पर access block हो जाता है
  • लेकिन Open from folder से Documents चुनने पर फिर से access संभव हो जाता है, और उसके बाद Open by consent भी बिना restriction के काम करता है
  • settings screen में access अब भी blocked दिखता है, लेकिन वास्तव में Insent Documents फ़ोल्डर तक लगातार पहुँच सकता है
  • access को पूरी तरह block करने के लिए tccutil reset All co.eclecticlight.Insent command चलाकर Mac को restart करना पड़ता है

• अंदरूनी कामकाज का विश्लेषण

  • Insent एक सामान्य notarized ऐप है और sandbox या किसी special permission का उपयोग नहीं करता
  • System Integrity Protection(SIP) enabled होने पर कुछ काम sandbox के तहत process होते हैं
  • sandboxd file access request को intercept करके TCC को approval request भेजता है, और उपयोगकर्ता की सहमति मिलने पर access दिया जाता है
  • access disable होने के बाद TCC request को reject करता है, लेकिन जब उपयोगकर्ता Open/Save panel के ज़रिए फ़ोल्डर चुनता है, तो sandboxd अब request intercept नहीं करता
  • इसके कारण TCC access को control नहीं कर पाता, और sandbox restrictions हटे हुए state में फ़ोल्डर access संभव हो जाता है

• समस्या का कारण

  • उपयोगकर्ता की intent के आधार पर access होने पर उस फ़ोल्डर के लिए sandbox restrictions हट जाती हैं
  • यह बदलाव Privacy & Security settings UI में reflect नहीं होता, इसलिए settings में block दिखने के बावजूद वास्तव में access allowed बना रहता है
  • दूसरे protected folders (जैसे Desktop, Downloads) सामान्य रूप से काम करते हैं, और यह समस्या हर फ़ोल्डर के लिए अलग-अलग होती है

• निष्कर्ष

  • Files & Folders item में access restriction का display वास्तविक लागू स्थिति के लिए भरोसेमंद नहीं है

    • भले ही कोई ऐप list में न दिखे या blocked दिखे, वास्तव में वह protected folder तक पहुँच सकता है
    • एक बार access permission मिल जाने पर terminal command और restart के बिना उसे हटाया नहीं जा सकता, जिससे उपयोगकर्ता के access control खोने का जोखिम पैदा होता है

• अतिरिक्त चर्चा (टिप्पणियों का सार)

  • परीक्षण के बाद Documents फ़ोल्डर में com.apple.macl extended attribute जुड़ जाता है, जो संभवतः Insent को access देने का काम करता है
  • tccutil reset command database की macl entries हटाता है, लेकिन xattr (extended attributes) बचे रह सकते हैं, जिससे access जारी रह सकता है
  • SIP enabled होने पर इस attribute को हटाना कठिन है, और recovery mode में xattr -d com.apple.macl path/to/Documents command से ही इसे delete किया जा सकता है
  • इस कारण उपयोगकर्ता के लिए ऐप की वास्तविक access स्थिति की पुष्टि करना या उसे control करना कठिन हो जाता है

[GN⁺]

Hacker News की राय

• मुझे यह एक सीधी-सादी समस्या लगती है। अगर किसी ऐप को किसी फ़ोल्डर तक पहुंच दी गई है, तो यह स्वाभाविक है कि वह उस फ़ोल्डर के अंदर की फ़ाइलों तक भी पहुंच सके

  • दस्तावेज़ ध्यान से पढ़ने चाहिए। Files & Folders सेटिंग असल permission स्थिति को सही तरीके से नहीं दिखाती। UI में भले blocked दिखे, ऐप फिर भी Documents फ़ोल्डर तक unrestricted access रख सकता है
  • मुख्य बात यह है कि “permission दिया गया था, फिर UI में बंद किया गया, लेकिन access फिर भी बना रहता है”
  • लेख की शुरुआत में भी साफ़ लिखा है कि “security settings ऐप की वास्तविक access स्थिति को गलत तरीके से दिखा सकती हैं”
  • उम्मीद थी कि macOS UI से जुड़े फ़ोल्डरों को पहचानकर backend में उसे जोड़ देगा, लेकिन इसे सिर्फ path exception की तरह handle किया जा रहा है, जिससे UI disable हो जाता है। लगता है यह feedback report के रूप में भेजा गया होगा। लेखक Gatekeeper या TCC से जुड़ी समस्याएँ अक्सर देखते हैं, इसलिए बात समझ आती है
  • लेख बहुत अस्पष्ट तरीके से लिखा गया है। permission हटने के बाद भी जो mechanism बचा रहता है, उसके बारे में पर्याप्त व्याख्या नहीं है

• लेख पढ़ने के बाद मैंने सभी folder permissions हटाकर test किया, और Insent UI में “None” दिखने के बावजूद Documents पढ़ पा रहा था। यह transparency failure लगता है

  • यह सवाल भी उठता है कि क्या ऐप को default रूप से user home folder तक पहुंच नहीं होती?

• यही GUI-केंद्रित OS की विडंबना है। Documents फ़ोल्डर की access को पूरी तरह block करने के लिए terminal में
  tccutil reset All co.eclecticlight.Insent
  command चलाकर reboot करना पड़ता है

  • यह देखकर Jobs भी कब्र में करवट बदलें। कहा जाता है कि NeXT के समय भी GUI बनाम CLI के ऐसे टकराव बहुत थे
  • GUI से जुड़ी एक और अजीब बात भी है। Wi‑Fi बंद करके shutdown किया था, लेकिन boot के बाद login करते समय Wi‑Fi icon थोड़ी देर के लिए active दिखा और फिर inactive हो गया। समझ नहीं आता यह सिर्फ UI bug है या वास्तव में थोड़ी देर के लिए चालू होता है

• शीर्षक को “macOS app, user द्वारा access हटाने के बाद भी folder access बनाए रखता है” जैसा होना चाहिए, तब ज़्यादा सही होगा

  • लेकिन वास्तव में user ने कोई specific access नहीं हटाया, सिर्फ general folder access हटाया था। fine-grained access को अलग-अलग हटाने का कोई तरीका नहीं है

• Mac का sandbox system मुझे Windows UAC की याद दिलाता है। यह बस user fatigue बढ़ाने वाली संरचना है।
  *nix का optional container approach मुझे कहीं बेहतर लगता है।
  Terminal से चलाए गए background process का parent process के मरने के बाद भी permissions बनाए रखना खास तौर पर अजीब है। पूरा permission model कुछ औपचारिक-सा लगता है

  • Apple को अपने पुराने ads फिर से देखने चाहिए (YouTube लिंक)
  • वैसे UAC security boundary नहीं है, इसलिए UAC-bypass को privilege escalation vulnerability नहीं माना जाता
  • बड़ी समस्या यह है कि आज भी बहुत से developers उसी पुराने paradigm में अटके हैं, जहाँ “हर चीज़ हर चीज़ तक पहुंच सकती है।” macOS का UX परफेक्ट नहीं है, लेकिन unlimited access को default रखना उससे भी ज़्यादा खतरनाक है
  • और Apple अपने खुद के apps के लिए exceptions भी रखता है। user experience खराब न हो, इसलिए
  • यह Mac का sandbox नहीं, बल्कि TCC system है। App Sandbox इस्तेमाल करने वाले apps तो Documents access prompt भी नहीं दिखा सकते। उनकी जगह Security Scoped Bookmark नाम के तरीके से access बनाए रखी जा सकती है (संदर्भ लिंक)

• tccutil reset के अलावा security settings में permission को on करके फिर off करने से भी reset किया जा सकता है।
  bug की वजह से UI state को गलत दिखाता है, लेकिन actual permissions ठीक से काम करती हैं।
  checkbox का रंग भी focus के हिसाब से बदलता है, जिससे और भ्रम होता है। Sequoia version में भी यह बना हुआ है।
  external drive पर installed games का “removable volumes” access माँगना और सूची में ढेर सारे entries के रूप में दिखना भी दिलचस्प है

• यह bug है, security vulnerability है, या सिर्फ गलती—समझना मुश्किल है। सोच रहा हूँ कि क्या सभी apps के लिए reset command चला देनी चाहिए

  • यह सिर्फ UI में omission है। अंदरूनी system सामान्य रूप से काम कर रहा है
  • इसे security UI bug के रूप में वर्गीकृत किया जाएगा। क्योंकि यह user को permission स्थिति समझने नहीं देता, इसलिए यह CVE के दायरे में भी आ सकता है
  • यह Apple की औपचारिक security प्रक्रिया और वास्तविक file access संरचना के टकराव का उदाहरण है। settings में permission स्थिति साफ़ दिखनी चाहिए, और revoke करने के बाद दोबारा grant करना थोड़ा कठिन होना चाहिए। और जिन permissions के लिए app restart चाहिए, उन्हें अब तो हटा देना चाहिए

• नवीनतम macOS में भी ऐसा ही security UI confusion है।
  “Full Disk Access” सेक्शन में कुछ apps greyed out दिखते हैं, लेकिन on और off की स्थिति में अंतर समझ नहीं आता।
  पता नहीं चलता कि यह bug है या वास्तव में permission मौजूद है

  • Apple की व्याख्या अस्पष्ट है। “Files & Folders” सूची सिर्फ permission request history दिखाती है
    Full Disk Access बंद करने पर भी कुछ sensitive folders ही सुरक्षित होते हैं, जबकि सामान्य folders (Desktop, Documents आदि) तक पहुंच फिर भी बनी रह सकती है (Apple दस्तावेज़)

• समस्या की जड़ Documents फ़ोल्डर पर सेट किया गया com.apple.macl extended attribute है। SIP की वजह से इसे हटाया नहीं जा सकता

  • यह bug नहीं, बल्कि दो security systems के UI mismatch की समस्या है। वास्तविक protection काम कर रही है, लेकिन UI उसे व्यक्त नहीं कर पाता

• सोचता हूँ क्या iOS में भी यही होता होगा

  • iOS में apps file picker या अपने खुद के folder के बाहर access नहीं कर सकते, इसलिए वही समस्या वहाँ नहीं होती