Vì sao không thể tin cậy cài đặt Privacy & Security trên macOS

 (eclecticlight.co)
1 điểm bởi GN⁺ 11 ngày trước | 1 bình luận | Chia sẻ qua WhatsApp
  • Đã xác nhận có vấn đề khi cài đặt Privacy & Security trên macOS không phản ánh trạng thái quyền truy cập thực tế
  • Dù quyền truy cập thư mục Documents đã bị chặn, ứng dụng Insent vẫn có thể đọc tệp
  • Khi người dùng trực tiếp chọn thư mục, hệ thống TCC coi đó là truy cập có chủ đích nên gỡ bỏ hạn chế
  • Trên màn hình cài đặt vẫn hiển thị là đã chặn, nhưng thực tế ràng buộc sandbox đã được gỡ và quyền truy cập vẫn tiếp tục được cho phép
  • Để chặn hoàn toàn quyền truy cập, cần dùng lệnh Terminal và khởi động lại, điều này có thể dẫn đến nguy cơ người dùng mất quyền kiểm soát

Vấn đề về độ tin cậy của cài đặt Privacy & Security trên macOS

  • Đã xác nhận có trường hợp cài đặt Privacy & Security trên macOS không phản ánh chính xác trạng thái quyền truy cập thực tế
    • Dùng một ứng dụng đơn giản tên Insent, có thể thấy hiện tượng vẫn truy cập được thư mục Documents dù trong phần cài đặt quyền đã bị chặn
    • Vấn đề này vẫn có thể được tái hiện giống hệt trên macOS 13.5 trở lên

  • Cách ứng dụng Insent hoạt động

    • Nút Open by consent mở và hiển thị một tệp văn bản bất kỳ trong thư mục Documents sau khi có sự đồng ý của người dùng
    • Nút Open from folder cho phép người dùng tự chọn thư mục, sau đó mở và hiển thị các tệp bên trong
    • Trong trường hợp thứ hai, ý định (intent) của người dùng được xem là cho phép truy cập, nên hệ thống TCC (Transparency, Consent, and Control) cho phép truy cập mà không cần thêm bước đồng ý nào

  • Quy trình thử nghiệm và kết quả

    • Sau khi cho phép truy cập Documents, xác nhận Insent đọc tệp bình thường
    • Sau đó tắt quyền truy cập Documents của Insent trong cài đặt Privacy & Security thì truy cập bị chặn
    • Tuy nhiên, nếu chọn Documents bằng Open from folder thì có thể truy cập trở lại, và sau đó Open by consent cũng hoạt động không bị giới hạn
    • Trên màn hình cài đặt vẫn tiếp tục hiển thị là quyền truy cập bị chặn, nhưng thực tế Insent vẫn tiếp tục truy cập được thư mục Documents
    • Muốn chặn hoàn toàn quyền truy cập thì phải chạy lệnh tccutil reset All co.eclecticlight.Insent và khởi động lại máy Mac

  • Phân tích cơ chế hoạt động bên trong

    • Insent là ứng dụng được công chứng thông thường (notarized), không dùng sandbox hay quyền đặc biệt
    • Khi System Integrity Protection (SIP) đang bật, một số thao tác sẽ được xử lý dưới dạng sandbox
    • sandboxd chặn các yêu cầu truy cập tệp và gửi yêu cầu phê duyệt tới TCC; nếu người dùng đồng ý thì truy cập được cho phép
    • Sau khi quyền truy cập bị vô hiệu hóa, TCC sẽ từ chối truy cập, nhưng nếu người dùng chọn thư mục qua bảng Open/Save thì sandboxd không còn chặn yêu cầu nữa
    • Vì vậy TCC không còn kiểm soát được truy cập, và có thể truy cập thư mục trong trạng thái ràng buộc sandbox đã được gỡ bỏ

  • Nguyên nhân của vấn đề

    • Khi phát sinh truy cập dựa trên ý định của người dùng, ràng buộc sandbox đối với thư mục đó sẽ bị gỡ bỏ
    • Thay đổi này không được phản ánh trong UI cài đặt Privacy & Security, nên nhìn thì có vẻ đang bị chặn nhưng thực tế trạng thái vẫn là được phép truy cập
    • Các thư mục được bảo vệ khác (ví dụ: Desktop, Downloads) hoạt động bình thường, và vấn đề này xảy ra độc lập theo từng thư mục

  • Kết luận

    • Không thể tin cậy hiển thị hạn chế truy cập trong mục Files & Folders là trạng thái áp dụng thực tế

      • Ngay cả khi ứng dụng không xuất hiện trong danh sách hoặc trông như đã bị chặn, vẫn có trường hợp nó thực sự truy cập được các thư mục được bảo vệ
      • Một khi quyền truy cập đã được cấp, không thể gỡ bỏ nếu không dùng lệnh Terminal và khởi động lại, làm tăng nguy cơ người dùng mất quyền kiểm soát truy cập

  • Thảo luận thêm (tóm tắt bình luận)

    • Sau thử nghiệm, thư mục Documents được cho là đã có thêm thuộc tính mở rộng com.apple.macl, đóng vai trò cho phép Insent truy cập
    • Lệnh tccutil reset xóa mục macl trong cơ sở dữ liệu, nhưng xattr (thuộc tính mở rộng) vẫn còn nên quyền truy cập có thể tiếp tục được duy trì
    • Khi SIP đang bật, rất khó xóa thuộc tính này; chỉ có thể xóa trong chế độ khôi phục bằng lệnh xattr -d com.apple.macl path/to/Documents
    • Vì vậy người dùng rơi vào tình huống khó kiểm tra hoặc kiểm soát trạng thái truy cập thực tế của ứng dụng

Bài viết liên quan

1 bình luận

 
GN⁺ 11 ngày trước
Ý kiến trên Hacker News

  • Theo tôi thì đây có vẻ là một vấn đề khá đơn giản. Nếu cấp cho ứng dụng quyền truy cập một thư mục thì đương nhiên phải dự đoán là nó cũng có thể truy cập các tệp bên trong thư mục đó

    • Cần đọc kỹ tài liệu. Thiết lập Files & Folders không phản ánh chính xác trạng thái quyền thực tế. Trên UI nó có thể trông như đã bị chặn, nhưng ứng dụng vẫn có thể truy cập không giới hạn vào thư mục Documents
    • Điểm mấu chốt là “đã cấp quyền rồi gỡ trên UI nhưng vẫn còn truy cập được”
    • Ngay phần mở đầu bài viết cũng nêu rõ rằng “thiết lập bảo mật có thể hiển thị sai trạng thái truy cập thực tế của ứng dụng”
    • Tôi từng kỳ vọng macOS sẽ nhận biết các thư mục đã được liên kết qua UI và đồng bộ ở backend, nhưng có vẻ nó chỉ được xử lý như một ngoại lệ đường dẫn đơn thuần nên UI bị vô hiệu hóa. Chắc hẳn kiểu này nên được gửi dưới dạng feedback report. Tác giả là người thường xuyên xử lý các vấn đề liên quan đến Gatekeeper hoặc TCC nên khá đồng cảm
    • Bài viết được viết quá mơ hồ. Phần giải thích về cơ chế khiến quyền vẫn còn sau khi bị gỡ là chưa đủ rõ

  • Sau khi đọc bài, tôi đã gỡ toàn bộ quyền thư mục và thử nghiệm, và Insent vẫn đọc được Documents dù UI hiển thị “None”. Có vẻ đây là một thất bại về tính minh bạch

    • Tự hỏi liệu có phải ứng dụng mặc định vốn đã có thể truy cập thư mục home của người dùng hay không

  • Đây đúng là sự trớ trêu của một hệ điều hành lấy GUI làm trung tâm. Muốn chặn hoàn toàn quyền truy cập thư mục Documents thì phải vào terminal và chạy
    tccutil reset All co.eclecticlight.Insent
    rồi khởi động lại

    • Chắc Jobs sẽ phải trở mình trong mộ. Nghe nói từ thời NeXT cũng đã có nhiều xung đột kiểu GUI đối đầu CLI như vậy
    • Cũng có những hiện tượng GUI kỳ quặc khác. Tôi đã tắt Wi‑Fi trước khi shutdown, nhưng khi boot lên và đăng nhập thì biểu tượng Wi‑Fi có vẻ sáng lên trong chốc lát rồi lại trở về trạng thái tắt. Không rõ chỉ là lỗi UI hay nó thực sự bật lên trong tích tắc

  • Tiêu đề nên được đổi thành kiểu như “ứng dụng macOS vẫn giữ quyền truy cập thư mục ngay cả khi người dùng đã gỡ quyền” thì sẽ chính xác hơn

    • Nhưng thực ra người dùng không gỡ một quyền truy cập cụ thể nào cả, mà chỉ gỡ quyền truy cập thư mục chung. Không có cách nào để gỡ từng quyền chi tiết riêng lẻ

  • Hệ thống sandbox của Mac làm tôi nhớ đến Windows UAC. Nó là kiểu thiết kế chỉ khiến người dùng thêm mệt mỏi.
    Tôi nghĩ cách dùng container có chọn lọc của *nix tốt hơn nhiều.
    Việc các tiến trình nền chạy từ Terminal vẫn giữ nguyên quyền ngay cả khi tiến trình cha đã chết là điều đặc biệt kỳ lạ. Toàn bộ hệ thống quyền cho cảm giác chỉ mang tính hình thức

    • Apple nên xem lại quảng cáo cũ của mình (liên kết YouTube)
    • Nhân tiện, UAC không phải là ranh giới bảo mật, vì vậy UAC-bypass không được xem là lỗ hổng leo thang đặc quyền
    • Vấn đề lớn hơn là vẫn còn rất nhiều nhà phát triển mắc kẹt trong mô thức cũ kiểu “mọi thứ có thể truy cập mọi thứ”. UX của macOS không hoàn hảo, nhưng để mặc định là truy cập không giới hạn còn nguy hiểm hơn
    • Hơn nữa, Apple còn đặt ngoại lệ cho chính ứng dụng của mình. Làm vậy để không phá vỡ trải nghiệm người dùng
    • Đây không phải sandbox của Mac mà là hệ thống TCC. Ứng dụng dùng App Sandbox thậm chí không thể hiện prompt xin quyền truy cập Documents. Thay vào đó, chúng có thể giữ quyền truy cập bằng cơ chế gọi là Security Scoped Bookmark (liên kết tham khảo)

  • Ngoài tccutil reset, cũng có thể đặt lại bằng cách bật rồi tắt quyền trong phần thiết lập bảo mật
    UI chỉ hiển thị sai trạng thái do lỗi, còn quyền thực tế vẫn hoạt động bình thường.
    Màu của checkbox cũng thay đổi tùy theo có focus hay không nên càng gây rối. Phiên bản Sequoia vẫn còn như vậy.
    Cũng khá thú vị khi các game cài trên ổ ngoài yêu cầu quyền truy cập “removable volumes” và xuất hiện dày đặc trong danh sách

  • Khó phân biệt đây là bug, lỗ hổng bảo mật hay chỉ là một sai sót đơn thuần. Tôi đang cân nhắc có nên chạy lệnh reset cho mọi ứng dụng không

    • Chỉ đơn giản là thiếu sót trên UI thôi. Hệ thống bên trong vẫn hoạt động bình thường
    • Kiểu này được xếp vào lỗi UI bảo mật. Vì nó khiến người dùng không thể nhận biết trạng thái quyền, nên thậm chí có thể là đối tượng của CVE
    • Đây là ví dụ cho thấy quy trình bảo mật mang tính hình thức của Apple xung đột với cấu trúc truy cập tệp thực tế. Trong Settings, trạng thái quyền cần được hiển thị rõ ràng, và sau khi gỡ thì việc cấp lại nên khó hơn. Ngoài ra, cũng nên bỏ dần kiểu quyền yêu cầu khởi động lại ứng dụng

  • Ngay trên macOS mới nhất cũng có sự rối rắm trong UI bảo mật tương tự.
    Trong mục “Full Disk Access”, một số ứng dụng hiển thị màu xám, nhưng không thể phân biệt đó là trạng thái bật hay tắt.
    Không thể biết đó là bug hay là ứng dụng thực sự đang có quyền

    • Cách giải thích của Apple khá mơ hồ. Danh sách “Files & Folders” chỉ đơn thuần hiển thị lịch sử yêu cầu quyền.
      Ngay cả khi tắt Full Disk Access, chỉ một số thư mục nhạy cảm được bảo vệ, còn các thư mục thông thường (Desktop, Documents, v.v.) vẫn có thể truy cập (tài liệu Apple)

  • Nguyên nhân của vấn đề là do thuộc tính mở rộng com.apple.macl được đặt trên thư mục Documents. Không thể xóa nó do SIP

    • Đây không phải bug mà là sự lệch nhau ở UI giữa hai hệ thống bảo mật. Việc bảo vệ thực tế vẫn hoạt động, chỉ là UI không thể hiện được điều đó

  • Tôi tự hỏi liệu trên iOS có hiện tượng tương tự không

    • Trên iOS, ứng dụng không thể truy cập ra ngoài file picker hoặc thư mục riêng của chính nó, nên sẽ không xảy ra cùng vấn đề này