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

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

Jadi, sebagai kelanjutan dari topik berbagi hak istimewa, hari ini kita akan berbicara tentang peluang. Jika Anda ingat, minggu lalu kita berbicara tentang bagaimana Unix menyediakan beberapa mekanisme untuk aplikasi yang dapat kita gunakan jika kita perlu memisahkan hak istimewa dari struktur internal aplikasi.

Hari ini kita akan berbicara tentang kemungkinan yang akan membuat kita berpikir sangat berbeda tentang hak istimewa yang mungkin dimiliki aplikasi. Karena itu, dalam kuliah hari ini kami memiliki dua masalah terpisah untuk dibahas. Satu pertanyaan adalah tentang bagaimana menghindari kebingungan dalam menentukan otoritas dan membuat hak istimewa Anda saat menulis sebuah program lebih jelas dan tidak ambigu sehingga Anda tidak sengaja menggunakan hak yang salah.

Pertanyaan kedua menyangkut "kotak pasir" yang disebut Capsicum , itu adalah sistem yang mirip dengan OKWS , yang akan memungkinkan Anda untuk menjalankan fragmen kode dengan hak yang lebih sedikit. Karena itu, jika sistem terganggu, maka ini tidak akan mengancam banyak kerusakan.



Pendekatan ini memungkinkan Anda untuk memanipulasi hak istimewa berbeda dari yang diizinkan Unix . Untuk memulainya, mari kita lihat masalah otoritas yang membingungkan ini, yang dihadapi oleh penulis artikel yang kita diskusikan Norman Hardy dan cari tahu mengapa dia begitu bingung olehnya.

Artikel ini sudah lama ditulis, dan penulis menggunakan struktur sintaksis untuk nama file, yang agak mengejutkan. Tapi kita bisa mencoba untuk paling tidak menuliskan masalahnya menjadi sintaks nama gaya Unix yang lebih akrab.

Sejauh yang saya tahu, dia menggunakan kompiler Fortran , yang terletak di / sysx / fort , dan dia ingin mengubah kompiler ini untuk menjaga statistik tentang apa yang dikompilasi, bagian mana dari kompiler yang paling intensif sumber daya dan sebagainya. Oleh karena itu, ia ingin memastikan bahwa kompiler Fortran ini entah bagaimana akan menyediakan entri dalam file / sysx / stat dan bahwa ia akan menulis di sini informasi tentang berbagai panggilan kompiler.



Sistem operasi mereka memiliki sesuatu seperti fungsi setuid yang kita bicarakan di Unix . Mereka menyebutnya lisensi file rumah. Ini berarti bahwa jika Anda menjalankan / sysx / fort , dan program ini memiliki apa yang disebut lisensi file rumah , maka proses yang baru saja Anda luncurkan akan memiliki izin menulis tambahan untuk semua yang ada di / sysx / . Artinya, Anda bisa menulis setelah memangkas segala sesuatu yang biasanya ditandai dengan tanda bintang, mendapatkan ekspresi dari bentuk / sysx / * . Ini memberi akses ke semua file yang ditulis dalam direktori setelah / , dan pengguna dapat menjalankannya. Oleh karena itu, masalah khusus yang mereka hadapi adalah bahwa beberapa jenis pengguna pintar dapat melakukan ini dengan menjalankan kompiler dapat mengambil banyak argumen seperti yang dilakukan GCC .

Pengguna seperti itu dapat, misalnya, mengumpulkan sesuatu seperti foo.f , di mana f adalah kode sumber Fortran , dan tambahkan di sini - o / sysx / stat .



Mereka memiliki file lain di sistem / sysx , yang merupakan file penagihan untuk semua klien sistem. Kerusakannya bahkan akan membuat lebih banyak kerusakan. Itu mungkin dengan cara yang mirip dengan "meminta" kompiler untuk mengkompilasi file sumber / sysx / bill dan meletakkannya di beberapa file khusus di / sysx . Dan dalam kasus mereka, itu berhasil. Terlepas dari kenyataan bahwa pengguna itu sendiri tidak memiliki akses tulis ke file atau direktori ini, ia menggunakan kompiler, yang memiliki hak istimewa tambahan ini - lisensi untuk file rumah. Berkat hak istimewa dari kompiler, ia dapat mengganti file yang bertentangan dengan niat pengembang.



Siapa yang harus mereka salahkan atas apa yang terjadi? Apa yang menurut mereka salah? Bisakah Anda bertindak berbeda agar tidak mengalami masalah seperti itu? Mereka percaya bahwa kompiler Fortran akan sangat berhati-hati ketika menggunakan hak istimewanya. Bahkan, pada tingkat tertentu, kompiler Fortran memiliki dua jenis hak istimewa yang digunakannya.

Satu, yang utama, didasarkan pada kenyataan bahwa jika pengguna memanggil kompiler, maka ia harus dapat mengakses file sumber, seperti foo.f. Dan jika itu adalah beberapa pengguna lain yang tidak mengaktifkan, atau tidak memanggil kompiler, maka pengguna tersebut tidak akan dapat mengakses kode sumber dari pengguna yang "benar".

Jenis hak istimewa kedua disediakan oleh lisensi ini, yang memungkinkan Anda untuk menulis file khusus ini. Pada tingkat internal kode sumber kompilator, harus ada instruksi yang jelas tentang hak istimewa mana yang ingin ia gunakan ketika membuka file atau ketika melakukan operasi istimewa. Itu bisa dengan mudah membuka, membaca dan menulis file seperti program lain. Secara implisit menggunakan semua hak istimewa yang dimilikinya, yaitu, dalam desain sistem mereka itu adalah semacam kombinasi hak pengguna dan lisensi untuk penggunaan file rumah.

Jadi, orang-orang ini benar-benar tertarik untuk menyelesaikan masalah ini. Dan mereka menyebut kompiler ini sebagai "pembantu yang bodoh," karena dia harus membedakan antara banyak hak istimewa yang dia miliki dan hati-hati menggunakannya jika perlu.

Jadi, kita harus mempertimbangkan bagaimana mengembangkan kompiler serupa di Unix . Dalam sistem mereka, semuanya terikat dengan lisensi file ini. Ada mekanisme lain yang kemudian mereka perkenalkan ke dalam program mereka untuk mengidentifikasi peluang, kami akan membicarakannya dalam waktu dekat. Tetapi bisakah kita menyelesaikan masalah ini pada sistem Unix ?

Misalkan Anda harus menulis kompiler Fortran ini di Unix , menulis file khusus ini, dan menghindari masalah. Apa yang akan kamu lakukan Ada ide? Saya pikir Anda dapat dengan mudah menyatakan ini rencana yang buruk, dan, misalnya, tidak menyimpan statistik. Atau tidak mendukung tipe input data - oh . Di sisi lain, Anda dapat menentukan kode sumber mana yang ingin Anda kompilasi sehingga Anda dapat membaca file / bill atau file statistik, yang mungkin perlu dirahasiakan.

Atau mungkin Anda bisa memberikan dukungan untuk kode sumber standar, tetapi kemudian harus mengandung bagian dari kode sumber lain, sehingga agak musykil.

Pemirsa: seseorang dapat berbagi hak penyusun.

Profesor: ya, itu akan menjadi desain lain yang berpotensi bagus untuk berbagi kepercayaannya. Kita tahu bahwa sebenarnya kompiler Fortran tidak membutuhkan kedua hak sekaligus. Jadi, mungkin, berbicara di Unix , kita dapat membuat kompiler seperti world / bin / fortcc , dan itu akan menjadi program reguler tanpa hak istimewa tambahan. Dan kemudian kita akan membuat / bin / fortlog , yang akan menjadi program khusus dengan beberapa hak istimewa tambahan, dan itu akan mengumpulkan statistik tentang apa yang terjadi di kompiler, dan fungsi fortcc akan memanggil fortlog . Jadi, hak istimewa apa yang akan kita berikan untuk benteng ini?



Pemirsa: mungkin jika Anda menggunakan sesuatu seperti setuid atau fortlog , maka pengguna lain juga dapat mendaftarkan data sewenang-wenang melalui itu.

Profesor: ya, jadi tidak terlalu bagus. Karena satu-satunya cara di Unix untuk memberikan hak istimewa tambahan pada fortlog adalah menjadi pemiliknya, saya tidak tahu, mungkin membuat fort UID dan setuid . Dan setiap kali Anda menjalankan fortlog , ia beralih ke fort UID itu . Dan, mungkin, beberapa file statistik khusus masih diperlukan di sini. Tapi setelah semua, semua orang bisa menyebut fortlog ini.



Dan ini tidak baik, karena siapa pun dapat menulis ke file statistik. Dalam hal ini, untuk keamanan, ini adalah masalah kecil, tetapi apa yang terjadi jika alih-alih stat, ini adalah file pembayaran tagihan ? Dalam hal ini, masalahnya akan jauh lebih serius.

Unix memiliki mekanisme yang agak rumit, yang kami hilangkan dari kuliah terakhir pada hari Senin. Mekanisme ini memungkinkan aplikasi untuk beralih di antara banyak uid . Dengan demikian, untuk menjalankan berbagai aplikasi, Anda dapat beralih di antara ID pengguna. Agak sulit dilakukan dengan cara yang benar, tetapi bisa dilakukan. Jadi mekanisme ini mungkin merupakan desain potensial dari sistem kami.

Saya pikir Anda bisa melakukan satu trik lagi: membuat fortlog "binary" hanya dapat dieksekusi untuk grup tertentu dan membuat fortcc setgid binary untuk grup itu. Namun, ini tidak terlalu baik, karena menghapus daftar grup yang awalnya dimiliki pengguna. Tapi siapa tahu, mungkin ini lebih baik daripada tidak sama sekali.

Bagaimanapun, ini adalah masalah yang agak rumit, tetapi dapat sepenuhnya diselesaikan dengan menggunakan mekanisme Unix . Mungkin Anda harus memikirkan kembali masalah Anda dan tidak terlalu khawatir tentang file statistik stat , mengutamakan keamanannya. Apa yang salah dalam proyek kami?

Ada dua hal yang harus diperhatikan jika terjadi kesalahan. Yang pertama disebut ambient otoritas , atau otoritas eksternal. Adakah yang mengerti apa artinya? Mereka tidak pernah memberikan definisi yang tepat ini.

Hadirin: ini berarti Anda memiliki otoritas yang diberikan kepada Anda oleh lingkungan. Seolah-olah Anda adalah pengguna yang bertindak tanpa batasan.

Profesor: ya, Anda sedang melakukan operasi, dan Anda dapat menunjukkan operasi mana yang ingin Anda lakukan, tetapi keputusan apakah operasi ini akan berhasil berasal dari beberapa parameter tidak langsung tambahan dalam proses Anda.

Di Unix, Anda bisa mengetahui seperti apa tampilan otoritas lingkungan. Karena itu, jika Anda melakukan panggilan sistem, Anda mungkin memberi nama panggilan sistem itu panggilan. Dan di dalam kernel, nama ini dipetakan ke beberapa objek. Dan objek ini seharusnya berisi di dalam dirinya sendiri semacam daftar kontrol akses, misalnya, izin untuk file ini dan seterusnya.



Dengan demikian, ada beberapa izin yang bisa Anda dapatkan dari objek ini, dan Anda perlu menentukan apakah operasi dengan nama ini yang diberikan kepada aplikasi akan diizinkan, yaitu rantai Nama -> Objek -> Izin dibuat . Inilah yang didapat aplikasi untuk melihat prosesnya.

Di dalam kernel, ada ID pengguna saat ini dari proses proses UID yang membuat panggilan. Dia juga terlibat dalam memutuskan apakah akan mengizinkan pelaksanaan operasi tertentu atau tidak. Dengan demikian, ID pengguna proses saat ini adalah hak istimewa eksternal. Kernel akan mencoba memverifikasi operasi apa pun yang ingin Anda lakukan menggunakan UID Anda saat ini, dan GID Anda saat ini, dan setiap hak istimewa tambahan lainnya yang mungkin Anda miliki. Dan sementara ada sejumlah hak istimewa yang memungkinkan Anda melakukan ini, Anda bisa melakukannya. Meskipun, ada kemungkinan bahwa Anda tidak ingin menggunakan semua hak istimewa ini untuk membuka file tertentu atau untuk melakukan operasi lainnya.

Apakah Anda mengerti apa itu hak- hak luar, hak-hak eksternal? Dalam kasus sistem operasi, ini berarti bahwa proses tersebut memiliki semacam ID pengguna. Bisakah Anda memberi contoh hak istimewa seperti itu yang tidak terkait dengan sistem operasi? Misalnya, ketika Anda melakukan operasi identifikasi proses untuk mengetahui apakah itu berhasil atau tidak. Firewall dapat berfungsi sebagai contoh - jika Anda berada di dalam jaringan atau memiliki alamat IP internal, Anda diizinkan untuk melakukan beberapa jenis operasi, dan jika Anda berada di luar jaringan, operasi yang sama akan dilarang untuk Anda.

Katakanlah Anda mengunjungi beberapa situs web yang berisi tautan ke server lain, dan mungkin Anda tidak ingin menggunakan hak istimewa yang harus Anda ikuti tautan ini. Karena mungkin ini akan memberi seseorang akses ke printer jaringan internal Anda dan seseorang akan dapat menggunakannya. Tetapi pada kenyataannya, orang yang memberi Anda tautan tidak boleh sampai ke printer Anda, karena itu berada di luar jaringan. Atau firewall browser Anda, dengan mengunjungi tautan ini, dapat melakukannya dengan cara curang.



Ini adalah sejenis moral yang setara dengan masalah membingungkan ini dalam model jaringan.

Pemirsa: Izin yang ada juga memengaruhi ini.

Profesor: ya.

Hadirin: karena Capsicum pada dasarnya menggunakan DAC - kontrol akses diskresioner.

Profesor: ya, ini sebagian besar karena orang-orang di Capsicum menggunakan sesuatu seperti kontrol akses diskresioner. Ini berarti bahwa pengguna atau pemilik objek memutuskan seperti apa kebijakan keamanan untuk objek ini. Untuk Unix, ini sangat alami - ini adalah file saya, dan saya dapat memutuskan apa yang ingin saya lakukan dengan mereka, saya bisa memberikannya kepada Anda atau menyimpannya. Jadi, hampir semua sistem DAC terlihat seperti ini karena mereka memerlukan semacam izin yang dapat diubah pengguna untuk mengelola kebijakan keamanan file mereka.



Sisi lain dari DAC adalah kontrol akses wajib. Kita akan membicarakan ini nanti, tetapi pada tingkat tertentu, sistem ini memiliki pandangan dunia yang sangat berbeda. Mereka berpikir bahwa Anda hanya pengguna komputer, dan orang lain menetapkan kebijakan keamanan untuk menggunakan komputer ini. Pandangan ini datang dari tahun 70-an atau 80-an, ketika militer benar-benar ingin memiliki sistem komputer rahasia di mana Anda bekerja pada beberapa hal yang ditandai sebagai "rahasia". Dan jika Anda mengerjakan hal-hal yang ditandai sebagai "rahasia", dan saya mengerjakan hal-hal yang berlabel "sangat rahasia," maka mereka tidak dapat dengan mudah membuat Anda. Tapi saya tidak perlu mengatur hak atas file dan sebagainya, itu hanya tidak diizinkan oleh semacam orang top.

Dengan demikian, kontrol akses wajib benar-benar mencoba untuk menempatkan berbagai jenis kebijakan akses di tempat pertama di mana ada pengguna dan pengembang aplikasi, dan selain itu, ada pria lain yang menetapkan kebijakan ini. Namun, seperti yang bisa Anda tebak, ini tidak selalu berhasil. Kami akan membicarakannya nanti. Tapi ini adalah arti penting dari kontrol akses diskresioner.

Kami memiliki banyak contoh lain menggunakan kontrol akses eksternal. Ini tidak selalu buruk, Anda hanya harus sangat berhati-hati saat menggunakannya. Jika Anda memiliki sistem privilege ambient , Anda harus sangat berhati-hati saat melakukan operasi privilege. Anda harus memastikan bahwa Anda benar-benar menggunakan izin yang benar dan Anda tidak akan tertipu secara tidak sengaja, seperti pada kompiler Fortran ini hampir 25 tahun yang lalu.

Jadi ini adalah salah satu interpretasi dari apa yang terjadi. Dan ini belum tentu satu-satunya cara untuk berpikir tentang apa yang salah, bukan? Kemungkinan lain adalah akan lebih baik jika aplikasi itu sendiri tahu jika harus mengakses file atas nama beberapa prinsip. Oleh karena itu, masalah nomor 2 adalah kompleksitas pemeriksaan kontrol akses.



Dalam arti, ketika kompiler Fortran sedang berjalan, ia membuka file atas nama pengguna, dan Anda perlu mengulangi logika yang sama yang kita lihat di sini dalam diagram, kecuali bahwa kompiler Fortran harus menghubungkan sesuatu yang lain untuk proses Sur UID . Alih-alih menggunakan hak istimewa saat ini, ia cukup mengulangi Nama -> Objek -> Pemeriksaan izin dan mencoba melakukan ini dengan serangkaian hak istimewa yang berbeda untuk proses UID kami .

Di Unix, ini cukup sulit dilakukan, karena ada banyak tempat di mana pemeriksaan keamanan dilakukan. Jika Anda memiliki tautan lunak simbolis, maka tautan simbolis dipindai, dan nama jalur juga dievaluasi dengan beberapa hak istimewa dan sebagainya. Tetapi mungkin terjadi bahwa dalam beberapa sistem Anda dapat menyederhanakan pemeriksaan kontrol akses jika itu dapat dilakukan secara mandiri dalam aplikasi. Tidakkah menurut Anda ini rencana yang cerdas? Apakah Anda setuju dengan itu? Apakah ada bahaya mengulang tes ini?

Hadirin: jika Anda melakukan pemeriksaan dalam aplikasi, Anda tidak bisa melakukan pemeriksaan lain.

Profesor: ya, Anda dapat dengan mudah melewatkan cek lain, ini benar sekali. Jadi, ketika mereka menggunakan kompiler Fortran di sini, ia bahkan tidak mencoba melakukan pemeriksaan, sehingga mereka gagal. Konsekuensi lain, selain kurangnya pemeriksaan, adalah bahwa kernel dapat berubah setiap saat, dan kemudian akan memiliki pemeriksaan yang sedikit berbeda. Ini akan memperkenalkan beberapa persyaratan keamanan tambahan, tetapi aplikasi tidak akan berubah dan akan menerapkan gaya pemeriksaan lama. Jadi ini bukan rencana yang bagus.

Ingatlah bahwa ada satu ide bagus di bidang keamanan - pengurangan jumlah mekanisme yang terlibat. Oleh karena itu, program ini hanya memiliki sejumlah kecil tempat di mana kebijakan keamanan diterapkan. Anda mungkin tidak ingin mengulangi fungsionalitas yang sama di aplikasi, di kernel, dan sebagainya. Anda benar-benar ingin memfokuskan pemeriksaan ini di satu tempat di program. Jadi, apa yang harus menjadi solusi untuk masalah pemberian otoritas?

Yang paling dekat dengan memecahkan masalah adalah kemampuan deskriptor file di Unix .



Dalam dunia kemungkinan, alternatif dari skema ini adalah bahwa alih-alih mengikuti rantai Nama -> Objek -> Izin dan memutuskan apakah akan menggunakannya berdasarkan izin eksternal dari proses proses UID , Anda dapat menggunakan skema yang sangat sederhana.

Misalkan Anda memiliki kemampuan yang terkait dengan objek tertentu. Dan fitur-fitur ini mungkin memiliki sejumlah batasan mengenai apa yang dapat Anda lakukan dengan objek ini.



Tetapi pada dasarnya, jika Anda memiliki peluang untuk objek ini, maka Anda dapat mengaksesnya. . , , , .
, Capability , , , , . . Capability , - , — .

Capability , . , ?

, , . , . , , .

, , , « ». , , Capsicum ? ?

: , , , Capability .

: , , , , . — . Unix , 0, , 1, . . , , . , - , , . PID , , PID:57 , . , , . , , , , , .. .



, , , . , -, - , .

, , , Unix , , , /etc/pwd .

. . , . , « »?



, , integer . , . , .

, . , ? , . , .

, , Capability , Fortran . sysx/fort ? , ?

: , . , , output- . , , .

: , . , Fortran /sysx/stat . , .

, , . , , «» Unix . , , , Fortran , , , , , .

. fort1 , , - , , foo.f , , , — o , . , . , .

, , , . ! , , , , setuid Fortran .



, setuid - , . , . , , , , .

, , , , . , , , Capability , , , , .

26:30

:

Kursus MIT "Keamanan Sistem Komputer". 6: «», 2


.

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

Dell R730xd 2 ? 2 Intel Dodeca-Core Xeon E5-2650v4 128GB DDR4 6x480GB SSD 1Gbps 100 $249 ! Cara membangun infrastruktur gedung. kelas menggunakan server Dell R730xd E5-2650 v4 seharga 9.000 euro untuk satu sen?