Kursus MIT "Keamanan Sistem Komputer". Kuliah 6: "Peluang", bagian 3

Institut Teknologi Massachusetts. Kursus Kuliah # 6.858. "Keamanan sistem komputer." Nikolai Zeldovich, James Mickens. Tahun 2014

Keamanan Sistem Komputer adalah kursus tentang pengembangan dan implementasi sistem komputer yang aman. Ceramah mencakup model ancaman, serangan yang membahayakan keamanan, dan teknik keamanan berdasarkan pada karya ilmiah baru-baru ini. Topik meliputi keamanan sistem operasi (OS), fitur, manajemen aliran informasi, keamanan bahasa, protokol jaringan, keamanan perangkat keras, dan keamanan aplikasi web.

Kuliah 1: “Pendahuluan: model ancaman” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 2: "Kontrol serangan hacker" Bagian 1 / Bagian 2 / Bagian 3
Kuliah 3: “Buffer Overflows: Exploits and Protection” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 4: “Pemisahan Hak Istimewa” Bagian 1 / Bagian 2 / Bagian 3
Kuliah 5: "Dari mana sistem keamanan berasal?" Bagian 1 / Bagian 2
Kuliah 6: “Peluang” Bagian 1 / Bagian 2 / Bagian 3

Pemirsa: jika UID ini menyediakan akses hanya baca ke file ini, dan Anda juga memiliki deskriptor file, maka jika Anda kehilangan UID , apakah Anda masih dapat izin untuk membaca file ini?

Profesor: ya, karena akan muncul dalam katalog. Karena begitu Anda menambahkan fitur ke file, itu saja. Ini terbuka untuk Anda dengan hak istimewa dan sebagainya. Namun masalahnya adalah mereka memiliki desain hybrid ini.

Artinya, kata mereka - Anda benar-benar dapat menambahkan fitur ke direktori dan Anda dapat membuka file baru, saat Anda bekerja secara paralel. Mungkin Anda menambahkan fitur ke direktori, seperti / etc , tetapi Anda tidak memiliki akses wajib ke semua file di direktori / etc. Tetapi begitu Anda masuk ke mode fitur, Anda dapat mencoba membuka file-file ini, mengetahui bahwa Anda memiliki akses ke direktori / etc. Lagi pula, itu sudah terbuka, jadi mengapa Anda tidak memberi saya file yang disebut "kata sandi" yang terletak di direktori ini?



Dan kemudian kernel perlu memutuskan apakah akan mengizinkan Anda untuk membuka file di direktori ini dalam mode baca atau tulis, atau apa yang Anda miliki. Jadi saya pikir ini adalah satu-satunya tempat Anda masih memerlukan hak istimewa eksternal ini, karena mereka mencoba membuat desain yang kompatibel, di mana mereka menggunakan semantik yang tidak terlalu alami untuk menggambarkan operasi direktori. Ini terlihat seperti satu-satunya tempat di mana prinsip-prinsip untuk mengatur sistem file Unix tetap ada.

Hadirin: apakah ada tempat lain seperti itu?

Profesor: pertanyaan yang bagus. Saya pikir saya harus mendapatkan kode sumber mereka sebelumnya untuk mencari tahu apa yang terjadi, tetapi sebagian besar situasi lainnya tidak benar-benar memerlukan verifikasi UID . Karena, misalnya, tidak digunakan untuk jaringan. Ini mungkin operasi sistem file yang biasa - jika Anda memiliki segmen memori bersama, Anda cukup membukanya dan hanya itu.

Hadirin: Bisakah Anda jelaskan lagi apa sebenarnya ID pengguna itu, jika Anda memiliki fitur Kemampuan ?

Profesor: ini penting ketika Anda memiliki kesempatan untuk membuat katalog. Pertanyaannya adalah, apa yang ada pada kesempatan ini bagi Anda? Pertimbangkan satu interpretasi, misalnya, keadaan kemampuan sistem yang bersih, bukan Capsicum . Jika dalam sistem seperti itu Anda memiliki peluang untuk direktori, maka Anda memiliki akses tanpa syarat ke semua file di direktori ini.

Di Unix, ini biasanya tidak terjadi. Anda dapat membuka direktori sebagai / etc , tetapi memiliki banyak file sistem di mana informasi rahasia dapat disimpan, misalnya, kunci pribadi server. Dan fakta bahwa Anda dapat membuka dan menggulir direktori ini tidak berarti Anda tidak dapat membuka file di direktori ini. Artinya, memiliki akses ke direktori, Anda memiliki akses ke file.

Di Capsicum , jika Anda membuka direktori / etc dan kemudian masuk ke mode fitur, berikut ini terjadi. Anda berkata: “Saya tidak tahu apa direktori ini. Saya hanya menambahkan deskriptor file ke situ. " Ada file yang disebut "kunci". Mengapa Anda tidak membuka file "kunci" ini ? Hanya karena pada saat itu, Anda mungkin tidak ingin proses berbasis fitur ini membuka file ini, karena Anda tidak memerlukannya. Meskipun ini memungkinkan Anda untuk memotong izin Unix untuk file tersebut.

Oleh karena itu, saya berpikir bahwa penulis artikel ini dengan hati-hati mendekati pengembangan sistem yang tidak akan melanggar mekanisme keamanan yang ada.

Hadirin: yaitu, Anda mengatakan bahwa dalam beberapa kasus Anda dapat menggunakan kombinasi dari dua faktor keselamatan ini? Artinya, meskipun pengguna dapat mengubah file di direktori, file apa yang dia akses tergantung pada ID penggunanya?

Profesor: ya, tepatnya. Dalam praktiknya, di Capsicum , sebelum Anda masuk ke mode fitur, Anda harus menebak file mana yang mungkin Anda perlukan nanti. Anda mungkin perlu pustaka bersama, file teks, templat, koneksi jaringan, dan sebagainya. Karena itu, Anda membuka semua ini sebelumnya. Dan tidak selalu perlu untuk mengetahui file mana yang Anda butuhkan. Jadi orang-orang ini membuatnya sehingga Anda cukup membuka deskriptor file direktori dan melihat file yang Anda butuhkan nanti. Namun, mungkin file-file ini tidak memiliki izin yang sama dengan yang Anda miliki. Justru karena alasan inilah kombinasi dua faktor keamanan digunakan - memeriksa kemampuan dan cairan pengguna. Jadi ini adalah bagian dari mekanisme kernel.



Mengapa mereka membutuhkan perpustakaan seperti libcapsicum ? Saya pikir ada dua hal utama yang mereka dukung di perpustakaan ini.

Salah satunya adalah mereka mengimplementasikan fungsi yang disebut lch_start , yang harus Anda gunakan alih- alih fungsi cap_enter . Fungsi lain yang disediakan libcapsicum adalah konsep daftar fd, yang digunakan untuk mengirimkan deskriptor file dengan angka. Tujuan daftar fd ini mudah dijelaskan. Ini pada dasarnya adalah generalisasi tentang bagaimana Unix mengelola dan meneruskan deskriptor file antar proses. Pada Unix dan Linux tradisional, yang Anda gunakan hari ini, beberapa deskriptor file diberikan ketika proses dimulai. Anda cukup membuka beberapa deskriptor file dengan nilai integer dari tabel ini dan memulai proses anak yang Anda butuhkan. Atau Anda menjalankan biner tertentu, dan mewarisi semua slot terbuka ini di tabel fd . Namun, tidak ada cara lain yang baik untuk memberi nama benda-benda ini selain menggunakan angka sebagai nama.

Perhatikan contoh di mana slot 0 akan digunakan untuk input, slot 1 untuk output, slot 2 untuk mencetak pesan kesalahan. Ini adalah cara kerjanya di Unix . Dan itu berfungsi dengan baik jika Anda hanya mentransfer tiga file ini atau tiga aliran data ke proses.



Namun dalam Capsicum, Anda "melewati" lebih banyak deskriptor file di jalur Anda. Jadi, ketika Anda melewati deskriptor file untuk beberapa file, Anda pergi melalui deskriptor file untuk koneksi jaringan, deskriptor untuk perpustakaan bersama yang Anda miliki, dan sebagainya. Mengelola semua angka ini cukup membosankan. Oleh karena itu, pada kenyataannya, libcapsicum menyediakan kemampuan untuk mengabstraksi dari nama deskriptor file sebelumnya antara proses menggunakan nama hierarkis yang digunakan sebagai ganti bilangan bulat yang tidak jelas ini.
Ini adalah salah satu hal sederhana yang mereka sediakan di perpustakaan mereka. Jadi saya bisa meneruskan deskriptor file ke proses dan memberinya nama, tidak masalah apa nomor yang ditunjukkan. Metode ini jauh lebih sederhana.

Mereka masih memiliki mekanisme peluncuran kotak pasir yang lebih rumit. Ini lch , API host kotak pasir yang digunakan alih-alih hanya memasuki mode fitur Kemampuan . Mengapa mereka membutuhkan sesuatu lebih dari sekadar entri sederhana ke mode kesempatan? Apa yang biasanya mengganggu Anda saat membuat kotak pasir?

Hadirin: mungkin, ia menghapus semua hal yang diwariskan untuk memastikan awal yang "bersih" dari sistem.

Profesor: ya. Saya pikir mereka khawatir tentang mencoba memperhitungkan segala sesuatu yang memiliki akses ke kotak pasir. Masalahnya adalah, jika Anda hanya memanggil cap_enter , secara teknis, di tingkat mekanisme kernel, itu akan berfungsi. Benar? Itu hanya mencegah Anda menemukan peluang baru.

Tetapi masalahnya adalah bahwa mungkin ada banyak hal yang sudah memiliki akses proses.

Oleh karena itu, saya pikir contoh paling sederhana adalah keberadaan deskriptor file terbuka di sana yang Anda lupakan, dan mereka hanya akan diwarisi oleh proses ini.



Misalnya, mereka menganggap tcpdump . Pertama, mereka mengubah tcpdump dengan hanya memanggil cap_enter bahkan sebelum mereka akan mengurai semua koneksi jaringan yang masuk. Di satu sisi, ini bekerja dengan baik karena Anda tidak bisa mendapatkan lebih banyak fitur Kemampuan . Tetapi kemudian, melihat deskriptor file terbuka, mereka menyadari bahwa Anda memiliki akses penuh ke terminal pengguna, karena Anda memiliki deskriptor file terbuka untuk itu. Sehingga Anda dapat mencegat semua penekanan tombol yang dibuat pengguna, dan sejenisnya. Jadi ini mungkin bukan rencana yang bagus untuk tcpdump . Karena Anda tidak ingin seseorang mencegat aktivitas keyboard Anda.

Oleh karena itu, dalam kasus tcpdump, mereka secara manual mengubah deskriptor file dan menambahkan beberapa fitur pada mereka untuk membatasi jenis operasi yang dapat Anda lakukan. Jika Anda ingat, di Capsicum, fitur ini juga memiliki bit tambahan ini menunjukkan kelas operasi yang dapat dilakukan untuk deskriptor file yang diberikan. Dengan demikian, mereka pada dasarnya menganggap bahwa file descriptor adalah 0. Ini menunjuk ke terminal pengguna tty. Awalnya, itu hanya pointer langsung ke struktur tty di kernel. Untuk membatasi jenis operasi yang dapat dilakukan untuk deskriptor ini, mereka memperkenalkan beberapa struktur beta menengah kemampuan di tengah. Dengan demikian, deskriptor file menunjuk ke struktur kapabilitas ini, dan itu sudah menunjuk ke file asli yang Anda coba akses. Dan struktur kapabilitas ini mengandung beberapa bit restriktif atau izin untuk objek deskriptor file yang dapat diimplementasikan.

Jadi, dengan entri data standar di tcpdump, Anda tidak dapat melakukan apa pun dengannya. Anda hanya dapat melihat bahwa itu ada, dan hanya itu. Untuk deskriptor file output, mereka memberikan kesempatan ketika Anda dapat menulis sesuatu untuk itu, tetapi tidak dapat mengubah catatan, yaitu, Anda tidak dapat membatalkan perubahan yang dibuat.



Jadi apa lagi yang bisa Anda khawatirkan tentang meluncurkan kotak pasir ? Saya berpikir tentang keadaan deskriptor file. Apakah ada hal lain yang penting? Saya pikir di Unix ini adalah deskriptor file dan memori.

Hal lain adalah bahwa orang-orang ini khawatir bahwa di ruang alamat Anda mungkin ada data rahasia yang dialokasikan sebelumnya. Dan proses yang akan Anda isolasi di kotak pasir dapat membaca semua memori yang tersedia. Jadi jika ada beberapa jenis kata sandi yang Anda periksa sebelumnya, ketika pengguna masuk, dan Anda belum membersihkan memori, maka proses ini akan dapat membacanya dan melakukan sesuatu yang "menarik".

Mereka memecahkan masalah ini dengan cara ini: di lch_start Anda harus menjalankan program "segar". Anda mengambil program dan mengemas semua argumen ke dalamnya, semua deskriptor file yang ingin Anda berikan padanya. Kemudian Anda memulai proses baru atau memulai operasi reisialisasi seluruh ruang memori virtual. Dan kemudian tidak ada keraguan bahwa proses ini tidak akan menerima hak istimewa tambahan untuk memengaruhi set data rahasia. Ini persis seperti apa yang Anda berikan ke fungsi lch_start , dalam hal nama biner, argumen, dan kemampuan program.

Audiens: apa yang terjadi jika proses yang Anda mulai mengandung binary setuid = 0 ?

Profesor: Saya pikir orang-orang ini tidak menggunakan "binary" setuid dalam mode fitur untuk menghindari beberapa interaksi aneh yang mungkin muncul. Mereka menerapkan aturan ini: Anda dapat memiliki program setuid yang mendapatkan hak istimewa dari biner setuid , dan kemudian dapat memanggil cap_enter atau lch_start . Tetapi begitu Anda masuk ke mode fitur, Anda tidak dapat mengembalikan preferensi tambahan.

Pada prinsipnya, ini bisa berhasil, tetapi akan sangat aneh. Karena, jika Anda ingat, satu-satunya hal di mana UID penting ketika Anda berada dalam mode fitur adalah membuka file di dalam direktori. Oleh karena itu, tidak jelas apakah ini benar-benar rencana yang sangat baik untuk mendapatkan hak istimewa tambahan atau jika ada kekurangan di dalamnya.

Hadirin: Sebelumnya, kami berbicara tentang mengapa perpustakaan tidak benar-benar mendukung pemisahan yang ketat antara kedua faktor keamanan. Tetapi kita tidak harus menggunakan lch_start ?

Profesor: itu benar. Misalkan Anda memiliki sesuatu seperti tcpdump , atau gzip - ini adalah hal lain yang bekerja dengan mereka. Anda menganggap bahwa aplikasi tersebut mungkin tidak terganggu, dan ada beberapa fungsi dasar dari aplikasi tersebut, dan Anda peduli tentang bagaimana perilakunya di kotak pasir. Dalam kasus tcpdump, ini adalah penguraian paket yang berasal dari jaringan, dalam kasus gzip itu membongkar file. Dan sampai titik tertentu, Anda menganggap bahwa prosesnya melakukan segalanya dengan benar, dan tidak akan ada kerentanan. Oleh karena itu, Anda memercayainya untuk menjalankan lch_start dan percaya bahwa ia akan membuat gambar dengan benar, mengonfigurasi semua fitur dengan benar, dan kemudian membatasi diri dari panggilan sistem lebih lanjut di luar mode kemampuan.

Dan kemudian Anda meluncurkan hal-hal berbahaya. Tetapi pada saat itu instalasi sudah benar, dan Anda tidak memiliki cara untuk keluar dari kotak pasir ini. Jadi, saya pikir Anda perlu melihat bagaimana Anda dapat menggunakan mode fitur untuk aplikasi sandbox.

Jadi kami berbicara sedikit tentang tcpdump . Bagaimana Anda mengisolasi proses ini? Contoh menarik lainnya adalah program gzip , yang memampatkan dan mendekompresi file. Jadi mengapa mereka khawatir tentang kotak pasir? Saya pikir mereka khawatir kode dekompresi berpotensi buggy, atau mungkin ada kesalahan dalam manajemen memori, manajemen buffer selama dekompresi, dan sebagainya.



Pertanyaan menarik lainnya adalah mengapa perubahan untuk gzip tampak jauh lebih rumit daripada untuk tcpdump ? Saya pikir ini karena bagaimana aplikasi disusun secara internal, kan? Karenanya, jika Anda memiliki aplikasi yang hanya mengompresi satu file atau membongkar satu file, maka itu normal untuk meluncurkannya saja tanpa mengubahnya dalam mode fitur. Anda cukup memberikannya standar baru untuk membongkar sesuatu, dan standar tersebut memberikan data yang tidak dibongkar pada output, dan ini akan berfungsi dengan baik.

Masalahnya, karena hampir selalu terjadi dengan metode kotak pasir seperti itu, adalah bahwa aplikasi sebenarnya memiliki logika proses yang jauh lebih kompleks. Misalnya, gzip dapat memampatkan banyak file sekaligus, dan sebagainya. Dan dalam hal ini, Anda memiliki semacam proses utama di bagian atas aplikasi, yang sebenarnya memiliki hak tambahan untuk membuka beberapa file, mengemasnya, dan sebagainya. Dan logika inti seringkali perlu menjadi proses pendukung lainnya. Dalam kasus gzip, aplikasi tidak terstruktur sehingga kompresi dan dekompresi bertindak sebagai proses terpisah. Oleh karena itu, mereka harus mengubah implementasi kernel gzip dan beberapa struktur aplikasi itu sendiri sehingga, selain hanya meneruskan data ke fungsi dekompresi, mereka dikirim melalui panggilan RPC atau benar-benar ditulis ke semacam deskriptor yang hampir file. Ini untuk mencegah masalah pihak ketiga dari terjadi dan membongkar tanpa hak istimewa. Satu-satunya hal yang bisa dilakukan gzip pada saat yang sama adalah mengembalikan data yang belum dibongkar atau dikompresi ke proses yang memanggilnya.

Pekerjaan rumah lainnya adalah bagaimana Anda benar-benar menggunakan Capsicum di OKWS ? Apa yang Anda pikirkan tentang ini? Akankah ini membantu? Apakah orang - orang OKWS akan senang untuk meningkatkan ke FreeBSD karena jauh lebih mudah digunakan? Bagaimana Anda menggunakan Capsicum di FreeBSD ?

Hadirin: Seseorang dapat menyingkirkan beberapa batasan ketat.

Profesor: ya, benar, kita bisa menggantinya dengan kehadiran direktori deskriptor dan kemampuan file. Anda tidak perlu membuat chroot yang membingungkan. Alih-alih menggunakan chroot dengan banyak hal kecil, Anda bisa mengatur izin dengan hati-hati. Anda bisa membuka file yang Anda butuhkan. Jadi ini sepertinya plus besar.

Selanjutnya, di OKWS , Anda memiliki layanan peluncuran OK , yang harus memulai semua proses induk. Segera setelah mereka mati, sinyal kembali ke okld untuk memulai kembali proses "mati". Dan hal ini harus dijalankan root , karena harus mengisolasi proses di kotak pasir. Tetapi ada beberapa hal dalam OKWS yang dapat ditingkatkan dengan Capsicum .

Misalnya, Anda bisa memberikan okld dengan hak istimewa yang jauh lebih sedikit. Karena, misalnya, untuk mendapatkan port 80, Anda memerlukan hak akses root. Tetapi setelah itu, Anda dapat dengan aman meletakkan segala sesuatu yang lain di kotak pasir, karena hak root tidak lagi diperlukan. Jadi itu sangat keren. Mungkin Anda bahkan dapat mendelegasikan proses hak untuk menanggapi permintaan orang lain, misalnya, proses pemantauan sistem yang hanya memiliki deskriptor proses ini atau deskriptor proses untuk proses anak dan setiap kali proses seperti itu crash, ia memulai yang baru. Karena itu, saya pikir kemampuan untuk membuat kotak pasir tanpa hak akses root sangat berguna.

Pemirsa: Anda dapat memberikan setiap proses deskriptor file yang memungkinkan Anda untuk hanya menambahkan entri ke log.

Profesor: ya, dan itu keren sekali. Seperti yang kami katakan terakhir kali, oklogd dapat "mengacaukan" dengan file log. Dan siapa yang tahu apa yang akan diizinkan kernel ketika dia memiliki deskriptor file dari file log itu sendiri. Namun, kami dapat lebih akurat menentukan kemampuan deskriptor file dengan memberikannya file log dan menunjukkan bahwa itu hanya dapat menulis tetapi tidak mencari apa pun. Dengan demikian, kita mendapatkan fungsi append-only jika Anda hanya "penulis" untuk file ini. Sangat nyaman. Anda dapat memberikan izin proses untuk menulis ke file, tetapi tidak membacanya, yang sangat sulit dilakukan hanya menggunakan izin Unix .

Capsicum ?

: , , , . , , , .

: , . Capsicum , , . .

: , , okld . , .

: , . . , , Capability , . , , , , , .
, OKWS . . , , , . .

, , «». , . , , , , . .
: «» , , ?

: , FreeBSD . , - , . FreeBSD Casper , , Capability . , «».

- , , , - , , Casper .



, «» . . , , , Casper - .

, , - . , Unix FD . , . , , .

, FreeBSD , DNS . DNS -, «». , tcpdump . tcpdump , IP-. , , DNS -.

, , DNS- DNS-, . Casper , DNS-.

, , , Capsicum? ? ? , , . Capsicum , ?

tcpdump GZIP , , . ?



: , , , . , Capability .

: , . Capsicum , , . , , . , , , , Capsicum , .

, «». , TCP — helper , , , , . , , , .

: , .

: , . . , . lth_start , . , , , - .

, , Capsicum . , , , . Unix - , .

, . , . , , . , .

, Chrome . , , , Unix, -, Unix .

, ?

: .

: . . , . , , , , .

Unix , . , . , . . , .

. Linux , setcall , , . , Capsicum , , Capsicum , . Linux setcall , . , , Linux .

, — , , , , . , - , «//», . Capsicum , , .


.

, . ? ? , 30% entry-level , : VPS (KVM) E5-2650 v4 (6 Cores) 10GB DDR4 240GB SSD 1Gbps $20 ? ( RAID1 RAID10, 24 40GB DDR4).

3 Dell R630 — 2 Intel Deca-Core Xeon E5-2630 v4 / 128GB DDR4 / 41TB HDD 2240GB SSD / 1Gbps 10 TB — $99,33 , , di sini .

Dell R730xd 2 kali lebih murah? Hanya kami yang memiliki 2 x Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 TV dari $ 249 di Belanda dan Amerika Serikat! Baca tentang Cara Membangun Infrastruktur Bldg. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?