1 poin oleh GN⁺ 2026-04-11 | 1 komentar | Bagikan ke WhatsApp
  • Ditemukan masalah pada pengaturan Privacy & Security di macOS yang tidak mencerminkan status izin akses sebenarnya
  • Bahkan saat akses ke folder Documents diblokir, aplikasi Insent masih tetap bisa membaca file
  • Ketika pengguna memilih folder secara langsung, sistem TCC menganggapnya sebagai akses yang disengaja dan mencabut pembatasan
  • Di layar pengaturan terlihat sebagai diblokir, tetapi sebenarnya pembatasan sandbox telah dicabut sehingga akses tetap diizinkan
  • Untuk memblokir akses sepenuhnya, diperlukan perintah Terminal dan restart, yang berisiko membuat pengguna kehilangan kendali

Masalah keandalan pengaturan Privacy & Security di macOS

  • Ditemukan kasus di mana pengaturan Privacy & Security di macOS tidak secara akurat mencerminkan status izin akses yang sebenarnya
    • Dengan aplikasi sederhana bernama Insent, muncul gejala bahwa akses ke folder Documents tetap memungkinkan meski di pengaturan ditampilkan sebagai diblokir
    • Masalah ini juga dapat direproduksi dengan cara yang sama pada macOS versi 13.5 ke atas
  • Cara kerja aplikasi Insent

    • Tombol Open by consent membuka dan menampilkan file teks acak di dalam folder Documents setelah mendapatkan persetujuan pengguna
    • Tombol Open from folder membuka dan menampilkan file di dalam folder yang dipilih langsung oleh pengguna
    • Dalam kasus kedua, niat (intent) pengguna dianggap sebagai izin akses, sehingga sistem TCC (Transparency, Consent, and Control) mengizinkan akses tanpa persetujuan tambahan
    Iklan
  • Prosedur eksperimen dan hasil

    • Setelah akses ke Documents diizinkan, dipastikan bahwa Insent dapat membaca file dengan normal
    • Setelah itu, ketika akses Documents untuk Insent dinonaktifkan di pengaturan Privacy & Security, akses pun diblokir
    • Namun, jika Documents dipilih lewat Open from folder, akses kembali menjadi mungkin, dan setelah itu Open by consent juga berjalan tanpa batasan
    • Di layar pengaturan tetap terlihat bahwa akses diblokir, tetapi pada kenyataannya Insent terus bisa mengakses folder Documents
    • Untuk memblokir akses sepenuhnya, perlu menjalankan perintah tccutil reset All co.eclecticlight.Insent lalu me-restart Mac
  • Analisis cara kerja internal

    • Insent adalah aplikasi notarized biasa dan tidak menggunakan sandbox maupun izin khusus
    • Saat System Integrity Protection(SIP) aktif, sebagian operasi diproses melalui sandbox
    • sandboxd mencegat permintaan akses file dan mengirim permintaan persetujuan ke TCC; ketika pengguna menyetujui, akses diizinkan
    • Setelah akses dinonaktifkan, TCC menolak akses, tetapi jika pengguna memilih folder melalui panel Open/Save, sandboxd tidak lagi mencegat permintaan tersebut
    • Akibatnya, TCC tidak lagi dapat mengendalikan akses, dan folder dapat diakses dalam keadaan pembatasan sandbox sudah dicabut
  • Penyebab masalah

    • Ketika akses terjadi berdasarkan niat pengguna, pembatasan sandbox untuk folder tersebut dihapus
    • Perubahan ini tidak tercermin di UI pengaturan Privacy & Security, sehingga di pengaturan tampak seolah diblokir, padahal sebenarnya akses tetap diizinkan
    • Folder terlindungi lain (misalnya Desktop, Downloads) bekerja normal, dan masalah ini terjadi secara terpisah per folder
  • Kesimpulan

    • Tampilan pembatasan akses pada item Files & Folders tidak bisa dipercaya sebagai status penerapan yang sebenarnya

      • Meskipun aplikasi tidak muncul di daftar atau tampak diblokir, ada kasus di mana aplikasi tersebut sebenarnya masih bisa mengakses folder terlindungi
      • Setelah izin akses diberikan sekali, izin itu tidak bisa dicabut tanpa perintah Terminal dan restart, sehingga berisiko membuat pengguna kehilangan kontrol akses
      Iklan
  • Diskusi tambahan (ringkasan komentar)

    • Setelah eksperimen, atribut ekstensi com.apple.macl ditambahkan ke folder Documents, dan diduga berperan dalam mengizinkan akses untuk Insent
    • Perintah tccutil reset menghapus entri macl di database, tetapi xattr (atribut ekstensi) tetap tersisa sehingga akses bisa terus bertahan
    • Saat SIP aktif, atribut ini sulit dihapus, dan hanya bisa dihapus dari mode pemulihan dengan perintah xattr -d com.apple.macl path/to/Documents
    • Karena itu, pengguna berada dalam situasi di mana sulit memeriksa atau mengendalikan status akses aplikasi yang sebenarnya

1 komentar

 
GN⁺ 2026-04-11
Komentar Hacker News
  • Menurut saya ini tampak seperti masalah yang sederhana. Jika sebuah aplikasi diberi izin akses ke folder, wajar jika diasumsikan aplikasi itu juga bisa mengakses file di dalam folder tersebut

    • Kita perlu membaca dokumentasinya dengan saksama. Pengaturan Files & Folders tidak secara akurat mencerminkan status izin yang sebenarnya. Di UI terlihat seperti diblokir, tetapi aplikasi masih bisa memiliki akses tanpa batas ke folder Documents
    • Intinya adalah “izin pernah diberikan, lalu dicabut di UI, tetapi akses tetap dimungkinkan”
    • Di bagian pembuka tulisan juga sudah disebutkan bahwa “pengaturan keamanan dapat salah menampilkan status akses aplikasi yang sebenarnya”
    • Saya berharap macOS bisa mengenali folder yang sudah terhubung melalui UI dan menyinkronkannya di backend, tetapi ternyata ini diperlakukan sebagai pengecualian jalur sederhana sehingga UI menjadi nonaktif. Sepertinya hal seperti ini layak dikirim sebagai feedback report. Penulisnya tampak sering menangani isu terkait Gatekeeper atau TCC, jadi mudah dipahami
    • Tulisan itu ditulis terlalu tidak jelas. Kurang penjelasan tentang mekanisme apa yang membuat akses tetap bertahan setelah izin dicabut
  • Setelah membaca tulisan itu, saya mencabut semua izin folder lalu mengujinya, dan Insent tetap bisa membaca Documents meski di UI tertulis “None”. Ini tampak seperti kegagalan transparansi

    • Jadi muncul pertanyaan apakah aplikasi pada dasarnya memang bisa mengakses folder home pengguna
  • Ini ironi dari OS yang berpusat pada GUI. Untuk benar-benar memblokir akses ke folder Documents, di terminal kita harus menjalankan
    tccutil reset All co.eclecticlight.Insent
    lalu reboot

    • Jobs pasti akan berbalik di kuburnya. Kabarnya bahkan di era NeXT benturan GUI vs CLI seperti ini juga sering terjadi
    • Ada juga gejala aneh terkait GUI. Saya mematikan Wi‑Fi lalu shutdown, tetapi saat boot dan login, ikon Wi‑Fi sempat terlihat aktif lalu kembali nonaktif. Tidak jelas apakah ini sekadar bug UI atau memang sempat menyala sesaat
  • Judulnya akan lebih akurat jika diubah menjadi “Aplikasi macOS mempertahankan akses folder meski pengguna mencabut aksesnya”

    • Tetapi pada kenyataannya pengguna bukan mencabut akses tertentu, melainkan hanya mencabut akses folder umum. Tidak ada cara untuk mencabut akses detail satu per satu
  • Sistem sandbox di Mac mengingatkan saya pada Windows UAC. Strukturnya hanya menambah kelelahan pengguna.
    Menurut saya pendekatan container opsional ala *nix jauh lebih baik.
    Sangat aneh bahwa proses latar belakang yang dijalankan dari Terminal tetap mempertahankan izin meskipun proses induknya sudah mati. Keseluruhan sistem izinnya terasa formalitas belaka

    • Apple perlu menonton lagi iklan lamanya (tautan YouTube)
    • Sebagai catatan, UAC bukan batas keamanan, jadi UAC-bypass tidak diperlakukan sebagai kerentanan eskalasi hak akses
    • Masalah yang lebih besar adalah masih banyak pengembang yang tetap berada dalam paradigma lama bahwa “semuanya bisa mengakses segalanya”. UX macOS memang tidak sempurna, tetapi akses tanpa batas sebagai default jauh lebih berbahaya
    • Selain itu Apple juga memberi pengecualian untuk aplikasinya sendiri. Alasannya demi menjaga pengalaman pengguna
    • Ini bukan sandbox Mac, melainkan sistem TCC. Aplikasi yang menggunakan App Sandbox bahkan tidak bisa menampilkan prompt akses Documents. Sebagai gantinya, akses dapat dipertahankan lewat mekanisme Security Scoped Bookmark (tautan referensi)
  • Selain tccutil reset, ini juga bisa diinisialisasi ulang dengan menyalakan lalu mematikan izin dari pengaturan keamanan.
    Hanya saja UI salah menampilkan status akibat bug, sementara izin sebenarnya tetap bekerja normal.
    Warna checkbox juga berubah tergantung fokus sehingga membingungkan. Ini masih terjadi bahkan di versi Sequoia.
    Menarik juga bahwa game yang dipasang di drive eksternal meminta akses ke “removable volumes” dan akhirnya menumpuk di daftar

  • Sulit membedakan apakah ini bug, celah keamanan, atau sekadar kekeliruan. Saya jadi bertanya-tanya apakah sebaiknya menjalankan perintah reset untuk semua aplikasi

    • Ini hanya kelalaian di UI. Sistem internalnya bekerja normal
    • Hal seperti ini dikategorikan sebagai bug UI keamanan. Karena membuat pengguna tidak dapat mengetahui status izin, ini bahkan bisa menjadi kandidat CVE
    • Ini contoh benturan antara prosedur keamanan formal Apple dan struktur akses file yang sebenarnya. Pengaturan seharusnya menampilkan status izin dengan jelas, membuat pemberian ulang lebih sulit setelah dicabut, dan sudah waktunya menghapus izin yang masih mewajibkan restart aplikasi
  • Di macOS terbaru pun masih ada kebingungan UI keamanan serupa.
    Di bagian “Full Disk Access”, beberapa aplikasi ditampilkan abu-abu sehingga sulit membedakan apakah statusnya aktif atau nonaktif.
    Tidak jelas apakah ini bug atau aplikasi itu benar-benar punya izin

    • Penjelasan Apple ambigu. Daftar “Files & Folders” hanya menampilkan riwayat permintaan izin.
      Bahkan jika Full Disk Access dimatikan, hanya beberapa folder sensitif yang tetap dilindungi, sementara folder umum (Desktop, Documents, dan sebagainya) masih bisa diakses (dokumen Apple)
  • Akar masalahnya adalah atribut ekstensi com.apple.macl yang disetel pada folder Documents. Karena SIP, atribut ini tidak bisa dihapus

    • Ini bukan bug, melainkan ketidakselarasan UI antara dua sistem keamanan. Perlindungan yang sebenarnya tetap berjalan, tetapi UI gagal merepresentasikannya
  • Saya penasaran apakah hal yang sama juga terjadi di iOS

    • Di iOS, aplikasi tidak bisa mengakses di luar file picker atau folder miliknya sendiri, jadi masalah yang sama tidak terjadi