Apa sebenarnya fitur "tak menentu" di El Capitan?

Saya baru saja belajar tentang fitur "Rootless" di El Capitan, dan saya mendengar hal-hal seperti "Tidak ada pengguna root", "Tidak ada yang bisa memodifikasi /System" dan "Dunia akan berakhir karena kita tidak bisa mendapatkan root".

Apa fitur "Rootless" dari El Capitan di tingkat teknis? Apa arti sebenarnya dari pengalaman pengguna dan pengalaman pengembang? sudo -sMasih akan bekerja, dan, jika demikian, bagaimana pengalaman menggunakan shell sebagai rootperubahan?

Pertama: nama "rootless" menyesatkan, karena masih ada akun root, dan Anda masih dapat mengaksesnya (nama resmi, "Perlindungan Integritas Sistem", lebih akurat). Yang benar-benar dilakukannya adalah membatasi kekuatan akun root, sehingga meskipun Anda menjadi root, Anda tidak memiliki kendali penuh atas sistem. Intinya, idenya adalah bahwa terlalu mudah bagi malware untuk mendapatkan akses root (mis. Dengan menghadirkan dialog auth kepada pengguna, yang akan menyebabkan pengguna secara refleks memasukkan kata sandi admin). SIP menambahkan lapisan perlindungan lain, yang tidak dapat ditembus malware meskipun sudah di-root. Bagian buruk dari ini, tentu saja, itu juga harus berlaku untuk hal-hal yang Anda lakukan dengan sengaja. Tetapi pembatasan yang dilakukan root tidak terlalu buruk; mereka tidak mencegah sebagian besar "normal"

Inilah yang membatasi, bahkan dari root:

• Anda tidak dapat mengubah apa pun di /System, /bin, /sbin, atau /usr(kecuali /usr/local); atau aplikasi dan utilitas bawaan apa pun. Hanya Penginstal dan pembaruan perangkat lunak yang dapat memodifikasi area ini, dan bahkan mereka hanya melakukannya saat menginstal paket yang ditandatangani Apple. Tetapi karena kustomisasi OS-X gaya biasa masuk /Library(atau ~/Library, atau /Applications), dan kustomisasi unix-style (misalnya Homebrew) masuk /usr/local(atau kadang /etc- kadang atau /opt), ini seharusnya tidak menjadi masalah besar. Ini juga mencegah penulisan tingkat blok ke disk startup, jadi Anda tidak dapat mem-bypassnya.

  Daftar lengkap direktori terbatas (dan pengecualian suka /usr/localdan beberapa lainnya) ada di /System/Library/Sandbox/rootless.conf. Tentu saja, file ini sendiri berada di area terbatas.

  Ketika Anda memutakhirkan ke El Capitan, itu memindahkan semua file "tidak sah" dari area terbatas ke /Library/SystemMigration/History/Migration-(some UUID)/QuarantineRoot/.

• Anda tidak dapat melampirkan ke proses sistem (misalnya yang berjalan dari lokasi sistem itu) untuk hal-hal seperti debugging (atau mengubah perpustakaan dinamis apa yang mereka muat, atau beberapa hal lain). Sekali lagi, tidak terlalu penting; pengembang masih dapat men-debug program mereka sendiri.

  Ini memang memblokir beberapa hal penting seperti menyuntikkan kode ke aplikasi Apple bawaan (terutama Finder). Ini juga berarti bahwa dtracealat berbasiskan untuk pemantauan sistem (mis. opensnoop) Tidak akan dapat memonitor & melaporkan banyak proses sistem.

• Anda tidak dapat memuat ekstensi kernel (kexts) kecuali ditandatangani dengan benar (yaitu oleh Apple atau pengembang yang disetujui Apple). Perhatikan bahwa ini menggantikan sistem lama untuk menegakkan penandatanganan kext (dan cara lama untuk mem-bypassnya). Tetapi sejak v10.10.4 Apple telah memiliki cara untuk memungkinkan dukungan trim untuk SSD pihak ketiga , alasan # 1 untuk menggunakan kex yang tidak ditandatangani telah hilang.

• Mulai dari Sierra (10.12), beberapa pengaturan konfigurasi launchd tidak dapat diubah (misalnya, beberapa daemon peluncuran tidak dapat diturunkan).

• Mulai di Mojave (10.14), akses ke informasi pribadi pengguna (email, kontak, dll) dibatasi untuk aplikasi yang telah disetujui pengguna untuk mengakses info itu. Ini umumnya dianggap sebagai fitur terpisah (disebut Personal Information Protection, atau TCC), tetapi didasarkan pada SIP dan menonaktifkan SIP juga menonaktifkannya. Lihat: "Apa dan bagaimana macOS Mojave menerapkan untuk membatasi akses aplikasi ke data pribadi?"

Jika Anda tidak ingin pembatasan ini - baik karena Anda ingin memodifikasi sistem Anda di luar apa yang diizinkan, atau karena Anda mengembangkan & men-debug sesuatu seperti kexts yang tidak praktis di bawah pembatasan ini, Anda dapat mematikan SIP. Saat ini ini membutuhkan reboot ke mode pemulihan dan menjalankan perintah csrutil disable(dan Anda juga dapat mengaktifkannya kembali csrutil enable).

Anda juga dapat menonaktifkan bagian SIP secara selektif . Sebagai contoh, csrutil enable --without kextakan menonaktifkan pembatasan ekstensi kernel SIP, tetapi meninggalkan perlindungan lainnya di tempatnya.

Tetapi tolong berhenti dan pikirkan sebelum menonaktifkan SIP, bahkan untuk sementara atau sebagian: apakah Anda benar-benar perlu menonaktifkannya, atau adakah cara yang lebih baik (sesuai SIP) untuk melakukan apa yang Anda inginkan? Apakah Anda benar-benar perlu memodifikasi sesuatu di /System/Libraryatau /binatau apa pun, atau bisakah itu pergi di tempat yang lebih baik seperti /Libraryatau /usr/local/binlain - lain? SIP mungkin "merasa" membatasi jika Anda tidak terbiasa, dan ada beberapa alasan yang sah untuk menonaktifkannya, tetapi banyak dari apa yang ditegakkan itu sebenarnya hanya praktik terbaik.

Untuk menggarisbawahi pentingnya meninggalkan sebanyak mungkin SIP diaktifkan sebanyak mungkin, pertimbangkan peristiwa 23 September 2019. Google merilis pembaruan ke Chrome yang mencoba mengganti tautan simbolis dari /varke /private/var. Pada kebanyakan sistem, SIP memblokir ini dan tidak ada efek buruk. Pada sistem dengan SIP dinonaktifkan, itu membuat macOS rusak dan tidak bisa di-boot. Alasan paling umum untuk menonaktifkan SIP adalah untuk memuat ekstensi kernel yang tidak disetujui (/ ditandatangani secara tidak benar) (khususnya driver video); jika mereka hanya menonaktifkan pembatasan kext, mereka tidak akan terpengaruh. Lihat utas dukungan resmi Google , tanya jawab pengguna super , dan artikel Ars Technica .

Referensi dan info lebih lanjut: presentasi WWDC tentang "Keamanan dan Aplikasi Anda" , penjelasan yang bagus dari Eldad Eilam di quora.com , ulasan Ars Technica dari El Capitan , dan artikel dukungan Apple tentang SIP , dan penyelaman mendalam oleh Rich Trouton ( yang juga memposting jawaban untuk pertanyaan ini ).

Bagi saya, itu berarti DTrace tidak lagi berfungsi.

DTrace mirip dengan ptrace / strace di Linux, dalam hal ini memungkinkan Anda untuk melihat apa yang dikatakan proses ke kernel. Setiap kali suatu proses ingin membuka file, menulis file, atau membuka port, dll, ia perlu menanyakan kernel. Di Linux, proses pemantauan ini terjadi di luar kernel di "userland", dan dengan demikian izinnya cukup halus. Seorang pengguna dapat memonitor aplikasi mereka sendiri (untuk memperbaiki bug, menemukan kebocoran memori, dll) tetapi perlu di-root untuk memantau proses pengguna lain.

Namun DTrace pada OSX bekerja pada level kernel, membuatnya jauh lebih berkinerja dan kuat, namun itu membutuhkan akses root untuk menambahkan probe ke dalam kernel dan dengan demikian melakukan apa saja. Seorang pengguna tidak dapat melacak proses mereka sendiri tanpa menjadi root, tetapi sebagai root mereka tidak hanya dapat menonton proses mereka sendiri, tetapi pada kenyataannya SEMUA proses pada sistem secara bersamaan. Misalnya, Anda dapat menonton file (dengan iosnoop) dan melihat proses mana yang membacanya. Ini adalah salah satu fitur paling berguna yang pernah ada untuk mendeteksi malware. Karena kernel juga berhubungan dengan jaringan IO, hal yang sama juga berlaku di sana. Wireshark mendeteksi aktivitas jaringan yang tidak biasa, DTrace memberi tahu Anda proses pengiriman data, bahkan jika itu tertanam ke dalam sistem seperti kernel itu sendiri.

Akan tetapi pada El Capitan, Apple sengaja mencegah DTrace bekerja - karena di dalamnya telah ditargetkan secara khusus dan dipilih sebagai sesuatu yang dibatasi oleh SIP. Mengapa mereka melakukan ini? Nah, sebelumnya Apple memodifikasi kernel dan DTrace mereka untuk memungkinkan beberapa proses untuk tidak dipantau melalui DTrace (yang mengganggu banyak peneliti keamanan pada saat itu karena beberapa proses sekarang terlarang bahkan sebagai root - termasuk malware). Alasan mereka untuk ini adalah untuk melindungi DRM di aplikasi seperti iTunes karena secara teoritis seseorang dapat DTrace dan mengambil data yang tidak-DRM keluar dari memori proses.

Namun, ada solusi penting yang memungkinkan para peneliti untuk terus melakukan pekerjaan mereka, dan itu adalah memodifikasi kernel untuk mengabaikan flag opt-out ini, sehingga DTrace masih dapat digunakan pada proses ini. Ini sebenarnya sangat bagus karena program mencoba menghindari deteksi di mana sekarang menyala dengan flag no-DTrace ini. Apa pun yang ingin disembunyikan Apple atau orang jahat sekarang ada di depan mata ...

Tapi itu tidak berfungsi sekarang, jadi bagaimana ini memengaruhi Anda? Nah, itu akan mempengaruhi Anda baik secara langsung maupun tidak langsung. Secara langsung, itu akan membatasi kemampuan Anda untuk memonitor sistem Anda. Sejumlah besar alat administrasi sistem dan pemantauan tingkat rendah (yang dibangun di atas alat tingkat tinggi) tidak lagi berfungsi. Efek tidak langsung akan jauh lebih besar - para profesional keamanan bergantung pada akses sistem yang dalam untuk mendeteksi jenis ancaman terburuk. Kami tidak bisa melakukan itu lagi. Sangat penting ketika menganalisis malware yang tidak tahu itu berjalan di debugger atau honeypot. Menonaktifkan SIP memberi tahu semua perangkat lunak, baik dari orang jahat dan Apple, bahwa sistem ini sedang diawasi. Tidak ada lagi yang menonton para penonton. Jika SIP adalah tentang keamanan mereka bisa mendidik pengguna tentang root - alih-alih mereka menghapusnya. Pada akhirnya ini berarti bahwa Apple telah menggantikan penghalang keamanan kata sandi root 'menjadi segalanya dan akhiri semua', dengan mekanisme perlindungan SIP 'menjadi segalanya dan akhiri semua'. Atau jika Anda mahir dalam rekayasa sosial, kata sandi root dengan reboot ...

Ada juga ini:

System Integrity Protection (SIP) adalah kebijakan keamanan keseluruhan dengan tujuan mencegah file sistem dan proses dari dimodifikasi oleh pihak ketiga. Untuk mencapai ini, ia memiliki konsep berikut:

• Perlindungan sistem file
• Perlindungan ekstensi kernel
• Perlindungan runtime

Perlindungan sistem file

SIP mencegah pihak selain Apple dari menambah, menghapus atau memodifikasi direktori dan file yang disimpan dalam direktori tertentu:

/bin
/sbin
/usr
/System

Apple telah mengindikasikan bahwa direktori berikut tersedia untuk diakses oleh pengembang:

/usr/local
/Applications
/Library
~/Library

Semua direktori /usrkecuali /usr/localdilindungi oleh SIP.

Dimungkinkan untuk menambah, menghapus atau mengubah file dan direktori yang dilindungi SIP melalui paket installer yang ditandatangani oleh otoritas sertifikat Apple sendiri. Ini memungkinkan Apple untuk membuat perubahan pada bagian OS yang dilindungi SIP tanpa perlu mengubah perlindungan SIP yang ada.

Otoritas sertifikat yang dimaksud disediakan oleh Apple untuk penggunaan mereka sendiri; Paket penginstal yang ditandatangani ID pengembang tidak dapat mengubah file atau direktori yang dilindungi SIP.

Untuk menentukan direktori mana yang dilindungi, Apple saat ini telah menetapkan dua file konfigurasi pada sistem file. Yang utama ditemukan di lokasi di bawah ini:

/System/Library/Sandbox/rootless.conf

di mana rootless.confdaftar semua aplikasi dan direktori tingkat atas yang dilindungi SIP.

Aplikasi

SIP melindungi aplikasi inti yang diinstal OS X ke dalam Aplikasi dan Utilitas Aplikasi. Ini berarti tidak mungkin lagi menghapus aplikasi yang diinstal OS X, bahkan dari baris perintah saat menggunakan hak akses root.

Direktori

SIP juga melindungi sejumlah direktori dan symlink di luar /Applicationsdan tingkat teratas dari direktori tersebut juga terdaftar di rootless.conf.

Selain perlindungan, Apple juga mendefinisikan beberapa pengecualian untuk perlindungan SIP dalam file rootless.conf, dan pengecualian itu ditandai dengan asterix. Pengecualian dari perlindungan SIP ini berarti bahwa dimungkinkan untuk menambah, menghapus, atau mengubah file dan direktori di dalam lokasi tersebut.

Di antara pengecualian itu adalah sebagai berikut:

• /System/Library/User Template - tempat OS X menyimpan direktori templat yang digunakan saat membuat folder rumah untuk akun baru.
• /usr/libexec/cups - tempat OS X menyimpan informasi konfigurasi printer

Apple menganggap file ini milik mereka dan bahwa perubahan pihak ketiga apa pun akan ditimpa oleh Apple.

Untuk melihat file mana yang telah dilindungi oleh SIP, gunakan lsperintah dengan huruf kapital O di Terminal:

ls -O

File yang dilindungi SIP akan diberi label sebagai dibatasi .

Satu pemikiran penting yang perlu diketahui adalah bahwa meskipun symlink dilindungi oleh SIP, itu tidak berarti bahwa direktori yang mereka tautkan sedang dilindungi oleh SIP. Pada level root dari boot drive OS X El Capitan, ada beberapa symlink yang dilindungi SIP yang menunjuk ke direktori yang disimpan di dalam direktori level root bernama private.

Namun, ketika isi privatedirektori diperiksa, direktori yang ditunjuk oleh symlinks tidak dilindungi oleh SIP dan keduanya beserta isinya dapat dipindahkan, diedit atau diubah dengan proses menggunakan hak akses root.

Selain daftar pengecualian SIP yang telah ditetapkan Apple rootless.conf, ada daftar pengecualian SIP kedua. Daftar ini mencakup sejumlah direktori dan nama aplikasi untuk produk pihak ketiga. Serupa dengan rootless.conf, daftar pengecualian ini adalah perubahan Apple dan pihak ketiga mana pun akan ditimpa oleh Apple.

/System/Library/Sandbox/Compatibility.bundle/Contents/Resources/paths

Perlindungan runtime

Perlindungan SIP tidak terbatas untuk melindungi sistem dari perubahan sistem file. Ada juga panggilan sistem yang sekarang dibatasi fungsinya.

• task_for_pid () / processor_set_tasks () gagal dengan EPERM
• Port khusus Mach diatur ulang pada exec (2)
• variabel lingkungan dyld diabaikan
• Probe DTrace tidak tersedia

Namun, SIP tidak memblokir inspeksi oleh pengembang aplikasi mereka sendiri saat sedang dikembangkan. Alat Xcode akan terus memungkinkan aplikasi untuk diperiksa dan didebug selama proses pengembangan.

Untuk detail lebih lanjut tentang ini, saya akan merekomendasikan untuk melihat dokumentasi pengembang Apple untuk SIP .

Perlindungan ekstensi kernel

SIP memblokir pemasangan ekstensi kernel yang tidak ditandatangani. Untuk menginstal ekstensi kernel pada OS X El Capitan dengan SIP diaktifkan, ekstensi kernel harus:

1. Ditandatangani dengan ID Pengembang untuk menandatangani sertifikat Kexts
2. Instal ke / Library / Extensions

Jika menginstal ekstensi kernel yang tidak ditandatangani, SIP harus dinonaktifkan terlebih dahulu.

Untuk informasi lebih lanjut tentang mengelola SIP, silakan lihat tautan di bawah ini:

Perlindungan Integritas Sistem - Menambahkan lapisan lain ke model keamanan Apple