เหตุใดจึงไม่อาจเชื่อถือการตั้งค่า Privacy & Security ของ macOS ได้

 (eclecticlight.co)
1 คะแนน โดย GN⁺ 19 일 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • มีการยืนยันปัญหาที่ การตั้งค่า Privacy & Security ของ macOS ไม่สามารถสะท้อนสถานะสิทธิ์การเข้าถึงจริงได้
  • แม้อยู่ในสถานะที่บล็อกการเข้าถึงโฟลเดอร์ Documents ก็ยังเกิดปรากฏการณ์ที่ แอป Insent ยังคงอ่านไฟล์ได้
  • เมื่อผู้ใช้เลือกโฟลเดอร์ด้วยตนเอง ระบบ TCC จะถือว่านี่คือการเข้าถึงที่ผู้ใช้ตั้งใจ และยกเลิกข้อจำกัด
  • แม้ในหน้าการตั้งค่าจะแสดงว่าเป็นการบล็อกอยู่ แต่ในความเป็นจริง ข้อจำกัดของแซนด์บ็อกซ์ถูกปลดออก ทำให้ยังคงอนุญาตการเข้าถึงต่อไป
  • หากต้องการบล็อกสิทธิ์การเข้าถึงอย่างสมบูรณ์ จำเป็นต้องใช้คำสั่งในเทอร์มินัลและรีสตาร์ตเครื่อง ซึ่งอาจนำไปสู่ความเสี่ยงที่ผู้ใช้สูญเสียการควบคุม

ปัญหาความน่าเชื่อถือของการตั้งค่า Privacy & Security บน macOS

  • พบกรณีที่ การตั้งค่า Privacy & Security ของ macOS ไม่สามารถสะท้อนสถานะสิทธิ์การเข้าถึงจริงได้อย่างถูกต้อง
    • โดยใช้แอปง่าย ๆ ชื่อ Insent พบปรากฏการณ์ที่ สิทธิ์เข้าถึงโฟลเดอร์ Documents สามารถใช้งานได้จริง แม้ในการตั้งค่าจะแสดงว่าโดนบล็อก
    • ปัญหานี้สามารถทำซ้ำได้เหมือนกันใน macOS เวอร์ชัน 13.5 ขึ้นไป

  • วิธีการทำงานของแอป Insent

    • ปุ่ม Open by consent จะเปิดและแสดงไฟล์ข้อความใดก็ได้ในโฟลเดอร์ Documents หลังจากได้รับความยินยอมจากผู้ใช้
    • ปุ่ม Open from folder จะเปิดและแสดงไฟล์ภายในโฟลเดอร์ที่ผู้ใช้เลือกเอง
    • ในกรณีหลังนี้ เจตนา(intent) ของผู้ใช้จะถูกมองว่าเป็นการอนุญาตการเข้าถึง ทำให้ระบบ TCC (Transparency, Consent, and Control) อนุญาตให้เข้าถึงได้โดยไม่ต้องมีการยินยอมเพิ่มเติม

  • ขั้นตอนการทดลองและผลลัพธ์

    • อนุญาตการเข้าถึง Documents ก่อน แล้วตรวจสอบว่า Insent สามารถอ่านไฟล์ได้ตามปกติ
    • จากนั้นปิดการเข้าถึง Documents ของ Insent ในการตั้งค่า Privacy & Security แล้วจะถูกบล็อกการเข้าถึง
    • แต่เมื่อเลือก Documents ผ่าน Open from folder ก็จะกลับมาเข้าถึงได้อีก และหลังจากนั้น Open by consent ก็ทำงานได้โดยไม่มีข้อจำกัด
    • แม้ในหน้าการตั้งค่าจะแสดงว่าการเข้าถึงยังถูกบล็อกอยู่ แต่ในความเป็นจริง Insent ยังเข้าถึงโฟลเดอร์ Documents ได้ต่อเนื่อง
    • หากต้องการบล็อกการเข้าถึงอย่างสมบูรณ์ ต้องรันคำสั่ง tccutil reset All co.eclecticlight.Insent และ รีสตาร์ต Mac

  • การวิเคราะห์การทำงานภายใน

    • Insent เป็นแอป notarized ทั่วไป และไม่ได้ใช้แซนด์บ็อกซ์หรือสิทธิ์พิเศษ
    • เมื่อ System Integrity Protection(SIP) เปิดใช้งานอยู่ บางการทำงานจะถูกจัดการในรูปแบบแซนด์บ็อกซ์
    • sandboxd จะดักจับคำขอเข้าถึงไฟล์และส่งคำขออนุมัติไปยัง TCC ซึ่งหากผู้ใช้ยินยอมก็จะอนุญาตการเข้าถึง
    • หลังจากปิดสิทธิ์การเข้าถึงแล้ว TCC จะปฏิเสธการเข้าถึง แต่ถ้าผู้ใช้เลือกโฟลเดอร์ผ่านแผง Open/Save sandboxd จะไม่ดักจับคำขอนี้อีกต่อไป
    • ส่งผลให้ TCC ไม่สามารถควบคุมการเข้าถึงได้ และ สามารถเข้าถึงโฟลเดอร์ได้ในสถานะที่ข้อจำกัดของแซนด์บ็อกซ์ถูกปลดออกแล้ว

  • สาเหตุของปัญหา

    • เมื่อเกิดการเข้าถึงตามเจตนาของผู้ใช้ ข้อจำกัดแซนด์บ็อกซ์สำหรับโฟลเดอร์นั้นจะถูกลบออก
    • การเปลี่ยนแปลงนี้ ไม่ถูกสะท้อนใน UI ของการตั้งค่า Privacy & Security ดังนั้นจึงดูเหมือนถูกบล็อกอยู่ แต่จริง ๆ แล้วสถานะยังคงอนุญาตการเข้าถึง
    • โฟลเดอร์ที่ได้รับการปกป้องอื่น ๆ (เช่น Desktop, Downloads) ทำงานได้ตามปกติ และปัญหานี้เกิดแยกกันเป็นรายโฟลเดอร์

  • บทสรุป

    • การแสดงสถานะการจำกัดสิทธิ์เข้าถึงในรายการ Files & Folders ไม่สามารถเชื่อถือได้ว่าเป็นสถานะที่ถูกใช้งานจริง

      • แม้แอปจะไม่แสดงอยู่ในรายการหรือดูเหมือนถูกบล็อก แต่ในความเป็นจริงอาจยังเข้าถึงโฟลเดอร์ที่ได้รับการปกป้องได้
      • เมื่อให้สิทธิ์การเข้าถึงไปแล้วหนึ่งครั้ง จะไม่สามารถเพิกถอนได้หากไม่มีคำสั่งเทอร์มินัลและการรีสตาร์ต ซึ่งเสี่ยงต่อการที่ผู้ใช้สูญเสียการควบคุมสิทธิ์การเข้าถึง

  • การอภิปรายเพิ่มเติม (สรุปความคิดเห็น)

    • หลังการทดลอง มีการคาดว่าแอตทริบิวต์ส่วนขยาย com.apple.macl ถูกเพิ่มเข้าไปในโฟลเดอร์ Documents และมีบทบาทในการอนุญาตให้ Insent เข้าถึง
    • คำสั่ง tccutil reset จะลบรายการ macl ออกจากฐานข้อมูล แต่ xattr (แอตทริบิวต์ส่วนขยาย) อาจยังคงอยู่ ทำให้การเข้าถึงยังดำเนินต่อไปได้
    • เมื่อ SIP เปิดใช้งานอยู่ จะลบแอตทริบิวต์นี้ได้ยาก และสามารถลบได้จากโหมดกู้คืนด้วยคำสั่ง xattr -d com.apple.macl path/to/Documents เท่านั้น
    • ด้วยเหตุนี้ ผู้ใช้จึงตกอยู่ในสถานการณ์ที่ ตรวจสอบหรือควบคุมสถานะการเข้าถึงจริงของแอปได้ยาก

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 19 일 전
ความคิดเห็นจาก Hacker News

  • สำหรับผมมันดูเหมือนปัญหาง่าย ๆ มาก ถ้าให้สิทธิ์แอปเข้าถึงโฟลเดอร์ ก็ควรคาดหมายได้ตามปกติว่าแอปจะเข้าถึงไฟล์ในโฟลเดอร์นั้นได้ด้วย

    • ต้องอ่านเอกสารให้ละเอียด การตั้งค่า Files & Folders ไม่ได้สะท้อนสถานะสิทธิ์จริงอย่างแม่นยำ แม้ใน UI จะดูเหมือนถูกบล็อก แต่แอปก็ยังเข้าถึงโฟลเดอร์ Documents ได้แบบ ไม่จำกัด
    • ประเด็นสำคัญคือ “เคยให้สิทธิ์ไว้แล้วแม้จะปิดใน UI ไปแล้วก็ยังเข้าถึงได้”
    • ต้นบทความก็ระบุไว้ชัดว่า “การตั้งค่าความปลอดภัยอาจแสดงสถานะการเข้าถึงจริงของแอปผิดพลาดได้”
    • เดิมคิดว่า macOS น่าจะรู้จักโฟลเดอร์ที่ผูกกับ UI อยู่แล้วและเชื่อมกับแบ็กเอนด์ให้เอง แต่กลับถูกจัดการเป็นข้อยกเว้นตาม path แบบง่าย ๆ จนทำให้ UI ใช้งานไม่ได้ น่าจะส่งเป็น feedback report ไปแล้ว ผู้เขียนก็เป็นคนที่แตะปัญหา Gatekeeper หรือ TCC บ่อย เลยเข้าใจความรู้สึกนี้
    • บทความเขียนได้ ไม่ชัดเจนเกินไป อธิบายไม่พอว่ากลไกไหนที่ทำให้สิทธิ์ยังคงอยู่แม้จะปิดไปแล้ว

  • หลังอ่านจบผมลองปิดสิทธิ์ทุกโฟลเดอร์แล้วทดสอบดู Insent ยังอ่าน Documents ได้ทั้งที่ใน UI แสดงว่า “None” ดูเหมือนเป็น ความล้มเหลวด้านความโปร่งใส

    • เลยสงสัยว่าโดยปกติแล้วแอปเข้าถึงโฟลเดอร์ home ของผู้ใช้ได้อยู่แล้วหรือเปล่า

  • นี่คือความย้อนแย้งของ OS ที่ยึด GUI เป็นหลัก ถ้าจะบล็อกการเข้าถึงโฟลเดอร์ Documents แบบสมบูรณ์ ต้องไปสั่งในเทอร์มินัล
    tccutil reset All co.eclecticlight.Insent
    แล้วรีบูต

    • Jobs คงพลิกตัวในหลุมศพไปแล้ว สมัย NeXT ก็ว่ากันว่ามีความขัดแย้งระหว่าง GUI กับ CLI แบบนี้เยอะ
    • ยังมีอาการแปลก ๆ ของ GUI อีกด้วย ปิดเครื่องทั้งที่ปิด Wi‑Fi ไว้แล้ว แต่พอบูตและล็อกอิน ไอคอน Wi‑Fi ดูเหมือนถูกเปิดอยู่ชั่วครู่ ก่อนจะกลับไปเป็นปิด ไม่รู้ว่าเป็นแค่บั๊กของ UI หรือว่ามันเปิดจริงชั่วขณะ

  • ถ้าจะตั้งชื่อให้ตรงกว่าเดิม น่าจะเป็น “แอปบน macOS ยังรักษาการเข้าถึงโฟลเดอร์ไว้ได้แม้ผู้ใช้จะปิดการเข้าถึงแล้ว”

    • แต่จริง ๆ แล้วผู้ใช้ไม่ได้ปิดการเข้าถึงแบบเฉพาะเจาะจง เพียงแค่ปิด การเข้าถึงโฟลเดอร์ทั่วไป เท่านั้น ยังไม่มีวิธีปิดสิทธิ์รายรายการแบบละเอียด

  • ระบบ sandbox ของ Mac ทำให้นึกถึง Windows UAC มันเป็นโครงสร้างที่มีแต่เพิ่มความเหนื่อยล้าให้ผู้ใช้
    ผมคิดว่าแนวทางคอนเทนเนอร์แบบเลือกใช้ของ *nix ดีกว่ามาก
    การที่โปรเซสเบื้องหลังที่รันจาก Terminal ยัง คงสิทธิ์ไว้ได้ แม้ parent process จะตายไปแล้ว ยิ่งดูประหลาด ทำให้ทั้งระบบสิทธิ์ดูเป็นพิธีกรรมเสียมากกว่า

    • Apple ควรกลับไปดูโฆษณาเก่า ๆ ของตัวเองอีกครั้ง (ลิงก์ YouTube)
    • อนึ่ง UAC ไม่ใช่ security boundary ดังนั้นการ bypass UAC จึงไม่ถูกนับเป็นช่องโหว่ยกระดับสิทธิ์
    • ปัญหาใหญ่กว่านั้นคือยังมีนักพัฒนาจำนวนมากที่ติดอยู่กับ กระบวนทัศน์เก่า ที่ว่า “ทุกอย่างเข้าถึงทุกอย่างได้” แม้ UX ของ macOS จะไม่สมบูรณ์แบบ แต่การปล่อยให้เข้าถึงได้ไม่จำกัดเป็นค่าเริ่มต้นอันตรายกว่า
    • แถม Apple ยังมี ข้อยกเว้นให้แอปของตัวเอง เพื่อไม่ให้ประสบการณ์ผู้ใช้เสียหาย
    • นี่ไม่ใช่ sandbox ของ Mac แต่คือ ระบบ TCC แอปที่ใช้ App Sandbox จะไม่สามารถแม้แต่จะแสดงพรอมป์ขอเข้าถึง Documents ได้ด้วยซ้ำ แต่สามารถคงการเข้าถึงไว้ด้วยวิธีที่เรียกว่า Security Scoped Bookmark (ลิงก์อ้างอิง)

  • นอกจาก tccutil reset แล้ว ยังรีเซ็ตได้โดยเปิดแล้วปิดสิทธิ์ใหม่ในหน้าตั้งค่าความปลอดภัย
    ปัญหาคือ UI มีบั๊กจนแสดงสถานะผิด แต่สิทธิ์จริงยังทำงานปกติ
    สีของเช็กบ็อกซ์ก็เปลี่ยนตามการโฟกัส เลยยิ่งชวนให้สับสน เรื่องนี้ยังเป็นอยู่ใน Sequoia เวอร์ชัน ด้วย
    และก็น่าสนใจที่เกมซึ่งติดตั้งบนไดรฟ์ภายนอกจะขอสิทธิ์เข้าถึง “removable volumes” จนขึ้นเต็มรายการไปหมด

  • แยกไม่ออกว่านี่เป็นบั๊ก เป็นช่องโหว่ความปลอดภัย หรือแค่ความผิดพลาดธรรมดา เลยลังเลว่าควรรันคำสั่ง reset กับทุกแอปดีไหม

    • มันเป็นแค่ สิ่งที่ตกหล่นใน UI ระบบภายในยังทำงานปกติ
    • เรื่องแบบนี้จัดเป็น บั๊กของ security UI เพราะทำให้ผู้ใช้ไม่สามารถรับรู้สถานะสิทธิ์ได้ จึงอาจเข้าข่าย CVE ได้
    • นี่เป็นกรณีที่ กระบวนการความปลอดภัยแบบพิธีการ ของ Apple ชนกับโครงสร้างการเข้าถึงไฟล์จริง ควรแสดงสถานะสิทธิ์ให้ชัดในหน้าตั้งค่า และควรทำให้การให้สิทธิ์ใหม่หลังจากปิดไปแล้วทำได้ยากขึ้น อีกทั้งสิทธิ์ที่ต้องให้แอปรีสตาร์ตก็ควรเลิกได้แล้ว

  • ใน macOS รุ่นล่าสุดก็ยังมี ความสับสนของ security UI คล้ายกัน
    ในรายการ “Full Disk Access” มีบางแอปที่แสดงเป็นสีเทา ซึ่งแยกไม่ออกว่าเป็นสถานะเปิดหรือปิด
    เลยไม่รู้ว่านี่คือบั๊กหรือว่าแอปมีสิทธิ์อยู่จริง

    • คำอธิบายของ Apple เองก็คลุมเครือ รายการ “Files & Folders” เป็นเพียงการแสดง ประวัติการร้องขอสิทธิ์ เท่านั้น
      Full Disk Access ต่อให้ปิดอยู่ ก็ยังปกป้องได้แค่บางโฟลเดอร์ที่อ่อนไหว ส่วนโฟลเดอร์ทั่วไปอย่าง Desktop, Documents ฯลฯ ก็ยังเข้าถึงได้อยู่ (เอกสารของ Apple)

  • ต้นเหตุของปัญหาคือแอตทริบิวต์ส่วนขยาย com.apple.macl ที่ถูกตั้งไว้บนโฟลเดอร์ Documents และลบออกไม่ได้เพราะ SIP

    • นี่ไม่ใช่บั๊ก แต่เป็น UI ที่ไม่สอดคล้องกันของระบบความปลอดภัยสองชุด การป้องกันจริงยังทำงานอยู่ เพียงแต่ UI แสดงออกมาไม่ได้

  • ชวนสงสัยว่าใน iOS จะมีอาการแบบเดียวกันไหม

    • iOS ไม่เปิดให้แอป เข้าถึงภายนอกตัวเลือกไฟล์หรือโฟลเดอร์ของตัวเองได้ ดังนั้นจึงไม่เกิดปัญหาแบบเดียวกัน