Tanda hitam - bagaimana OpenShift melindungi terhadap kerentanan kontainer dengan SELinux

Pernahkah Anda melakukan pekerjaan yang sulit untuk kebaikan masyarakat, tetapi tidak memperhatikan upaya Anda, karena Anda telah mendapat manfaat begitu lama sehingga Anda semua terbiasa? Ini adalah jenis pekerjaan untuk Anda yang dilakukan semua anggota komunitas SELinux .



Dan pada tanggal 18 Februari tahun ini, sebagian besar berkat pekerjaan mereka, dunia diselamatkan dari kerentanan pemukul kontainer yang berbahaya CVE-2019-5736 .

Meskipun ada sistem operasi lain dan proyek sumber terbuka lainnya yang menggunakan kontrol jenis dan kategori, jarang semua komponen yang dikonfigurasi dengan SELinux dimasukkan di luar kotak, secara default, dan siap untuk digunakan. Yang lebih jarang lagi, konfigurasi ini mencakup semua level, hingga solusi untuk orkestrasi wadah, atas dasar di mana cloud publik berfungsi.

Selama delapan tahun sekarang, Red Hat OpenShift telah menggunakan mekanisme kontrol akses paksa Linux seperti jenis penegakan (TE) dan keamanan multi-kategori (MCS). SELinux telah digunakan di OpenShift sejak 2011. Di Red Hat OpenShift Online, layanan hosting yang tersedia untuk umum di mana ribuan pengembang menjalankan kode kontainer setiap hari, SELinux telah digunakan sejak awal. Bagaimana dengan versi OpenShift yang digunakan, misalnya, di pusat data operator seluler favorit Anda? Bahkan, modul keamanan SELinux termasuk dalam Platform Red Hat OpenShift Container secara default, secara default! Dan tidak hanya dihidupkan, tetapi sepenuhnya dikonfigurasi dan siap untuk melindungi terhadap ancaman nyata.

Tidak seperti distribusi Kubernet lainnya, Red Hat menutup celah antara Linux dan platform orkestrasi wadah yang terpasang di atasnya. Yaitu, Red Hat OpenShift memantau dan menghilangkan ancaman keamanan di seluruh tumpukan, dan tidak hanya dalam satu lapisan. Dan ini dilakukan secara default - sejak hari pertama kerja.

OpenShift menggunakan konfigurasi ini secara default di Red Hat Enterprise Linux (Anda bahkan tidak perlu tahu apa yang ada di sana). Masalahnya tidak terbatas pada menjalankan setenforce 1 pada laptop. Aturan kontrol akses untuk tipe dan kategori yang digunakan penyewa untuk bekerja dengan wadah pada satu kluster Kubernetes dapat diperluas ke ratusan node yang dapat digunakan oleh ribuan penyewa lainnya.

Pikirkan tentang bagaimana konfigurasi SELinux dengan MCS akan terlihat setelah beberapa tahun digunakan di perusahaan besar yang mendistribusikan kredensial OpenShift ke kiri dan kanan. Sekarang bayangkan Anda memberikan kredensial Anda untuk masuk ke cluster OpenShift Anda, seperti yang kami lakukan di openshift.com. Loyalitas SELinux seringkali gagal dikenali untuk semua yang dilakukannya dalam solusi OpenShift. Jika menurut Anda sistem operasi saat ini tidak begitu penting, pikirkan apakah Anda dilindungi dari kerentanan CVE-2019-5736 hingga Februari ini. Di OpenShift, CVE-2019-5736 dilindungi dari awal, dan Anda dapat beralih ke solusi ini sekarang .

Tanda SELinux

Salah satu fitur keamanan default paling efektif yang diterapkan di Red Hat OpenShift adalah Security-Enhanced Linux (SELinux). SELinux adalah modul keamanan kernel Linux yang menyediakan kontrol akses berbasis kebijakan keamanan. Cara SELinux bekerja adalah menetapkan label (nama) untuk semua proses dan objek sistem operasi. Dengan demikian, setiap elemen yang terlibat dalam operasi kernel ditandai dan diklasifikasikan, dan kemudian diberikan akses berdasarkan seperangkat aturan yang ada.

Aturan kebijakan menentukan hubungan antara proses yang ditandai dan objek yang ditandai. Aturan yang ditentukan oleh pengguna dalam kebijakan diterapkan pada level kernel. Secara default, apa pun yang tidak diizinkan secara otomatis ditolak - dengan analogi dengan firewall yang menolak akses ke semua proses yang izin eksplisitnya tidak dikonfigurasi. Ilustrasi di bawah ini mengilustrasikan kasus penggunaan sederhana.

Bayangkan sebuah sistem di mana Anda perlu mendefinisikan jenis untuk objek seperti kucing dan anjing. Kucing dan anjing adalah jenis proses.


* Semua gambar dibuat oleh Máirín Duffy

Kelas objek dengan mana proses akan berinteraksi adalah umpan. Tambahkan jenis umpan: cat_chow dan dog_chow (Ohm-nom-nom).


Kami menetapkan izin bagi anjing untuk makan makanan anjing (dog_chow), dan untuk makanan kucing - kucing (cat_chow). Kami menulis izin ini sebagai aturan kebijakan SELinux:

allow cat cat_chow:food eat; allow dog dog_chow:food eat; 

Menurut aturan ini, proses "kucing" akan diizinkan pada tingkat kernel untuk makan makanan dengan label cat_chow, dan untuk anjing - makanan dengan label dog_chow.


Tapi kita ingat bahwa di SELinux, secara default, semuanya dilarang. Karena itu, jika anjing mencoba memakan cat_chow, intinya tidak akan mengizinkannya.


Ini adalah kontrol tipe, yang memainkan peran utama dalam melindungi sistem host dari proses kontainer. Proses kontainer hanya dapat membaca dan menjalankan file dari direktori / usr dan menulis data hanya untuk file kontainer. Pembatasan ini secara andal melindungi inang dari wadah, tetapi tidak melindungi beberapa wadah dari yang lain, karena semuanya ditandai dengan jenis yang sama. Untuk melindungi wadah dari satu sama lain, Anda harus menerapkan kontrol tag MCS.

MCS tidak menarik ekor kucing

Penggunaan MCS tidak secara langsung terkait dengan perlindungan OpenShift dari CVE-2019-5736 , tetapi berguna untuk membiasakan diri dengan topik ini untuk lebih memahami prinsip-prinsip menggunakan SELinux di OpenShift. Menetapkan label MCS dari sudut pandang pengguna atau administrator sistem cukup sederhana. Anda hanya perlu mengonfigurasi serangkaian kategori yang merupakan label teks sederhana (misalnya, Fido atau Spot), dan menambahkan pengguna ke dalamnya. Administrator sistem terlebih dahulu mengatur kategori dan kemudian menambahkan pengguna ke mereka, setelah itu pengguna dapat menggunakan label ini sesuai keinginan. Ini nyaman karena MCS memungkinkan Anda untuk menggunakan tag SELinux standar untuk mengelola objek. Mari kita kembali ke sistem imajiner dari contoh di atas.

Tambahkan bagian lain dari label yang akan diterapkan pada proses anjing dan umpan dog_chow. Tetapkan proses "dog" ke dog: random1 (Fido) dan dog: random2 (Spot).


Mari kita berikan label dog_chow: random1 (Fido) dan dog_chow: random2 (Spot) ke makanan anjing.


Menurut prinsip-prinsip operasi MCS, jika aturan kontrol paksa menurut jenis diamati dan tag MCS sewenang-wenang sama persis, maka akses diperbolehkan, dan dalam semua kasus lainnya ditolak.

Upaya oleh Fido (anjing: random1) untuk makan cat_chow: makanan akan ditolak karena kontrol tipe paksa.

Pertahanan secara mendalam

Modul keamanan SELinux default yang digunakan oleh OpenShift adalah contoh utama pertahanan secara mendalam. OpenShift, seperti banyak platform berbasis Kubernetes lainnya, menggunakan kebijakan SCC / PSP yang melarang menjalankan kontainer dengan hak akses root. Batasan ini juga melindungi terhadap CVE-2019-5736 . Di OpenShift, kontainer yang dimiliki oleh pengguna root diblokir secara default, tetapi parameter ini dapat diubah . Bahkan jika Anda mengizinkan kontainer berjalan sebagai root, konfigurasi SELinux standar di OpenShift masih melindungi terhadap CVE-2019-5736 . Ini adalah tingkat perlindungan lain yang benar-benar terbayar dalam situasi ini dan itu jauh dari satu-satunya di OpenShift. Informasi lebih lanjut dapat ditemukan dalam dokumen 10 tingkat keamanan wadah .

Untuk informasi lebih lanjut tentang CVE-2019-5736 , termasuk tambalan Red Hat Enterprise Linux untuk runtime kontainer, lihat tinjauan kerentanan Red Hat .