3 poin oleh GN⁺ 2024-09-06 | 2 komentar | Bagikan ke WhatsApp

Perubahan cara distribusi kode sumber RHEL oleh Red Hat

  • Pada Juni 2023, Red Hat mengambil keputusan kontroversial untuk mengubah cara distribusi kode sumber di balik Red Hat Enterprise Linux (RHEL)
  • Keputusan ini menimbulkan banyak pertanyaan tentang kelangsungan hidup downstream rebuild dari RHEL seperti Rocky Linux, AlmaLinux, dan Oracle Linux
  • Masing-masing distribusi kemudian membuat pengumuman untuk menenangkan komunitas
  • Banyak komunitas open source menafsirkan keputusan Red Hat sebagai pengaruh perusahaan yang serakah
  • Orang-orang mengatakan mereka pindah ke Debian, atau sudah pindah, demi mencari tempat berlindung

Pentingnya dan sulitnya keamanan

  • Keamanan itu sulit, membosankan, tidak menyenangkan, dan membutuhkan banyak upaya bila ingin dilakukan dengan benar
  • Debian tidak mengerahkan cukup usaha untuk melindungi penggunanya

Adopsi SELinux oleh Red Hat dan penyediaan kebijakan bawaan

  • Red Hat sudah lama menerima penggunaan SELinux, dan melangkah lebih jauh daripada sekadar mengaktifkan fitur itu di kernel
  • Mereka melakukan pekerjaan berat untuk membuat kebijakan SELinux bawaan bagi distribusi mereka
  • Kebijakan ini disediakan dalam keadaan aktif secara default di RHEL, dan membantu melindungi daemon serta server yang paling umum digunakan di antara berbagai daemon dan server yang berjalan secara default di RHEL
  • Apache, nginx, MariaDB, PostgreSQL, OpenSSH, dan lainnya semuanya dilindungi oleh kebijakan SELinux yang disediakan dalam distribusi RHEL

Penerapan kebijakan SELinux pada container

  • Perlindungan ini meluas hingga ke container
  • Container semakin menjadi cara yang disukai developer untuk mendistribusikan software
  • Mengira bahwa menjalankan sesuatu di dalam container pada dasarnya aman adalah sebuah kesalahpahaman
  • Container sendiri menyelesaikan masalah distribusi software, bukan masalah keamanan
  • Pada distribusi berbasis Red Hat, Anda dapat menggunakan podman, alternatif Docker yang memungkinkan menjalankan container tanpa daemon dan sepenuhnya rootless
  • Red Hat melangkah lebih jauh dengan menerapkan kebijakan SELinux bawaan yang kuat untuk memisahkan container dari OS host dan dari container lain
  • Menerapkan kebijakan SELinux pada container memberikan pengaman yang diperkuat untuk mengurangi risiko kerentanan masa depan yang belum diketahui

Upaya Red Hat menyediakan kebijakan SELinux bawaan

  • Red Hat tahu bahwa tanpa melakukan pekerjaan untuk kebijakan bawaan ini, pengguna tidak akan mengadopsi teknologi tersebut dan jutaan server akan tetap dalam keadaan rentan
  • SELinux itu sulit, dan bahasa kebijakan serta alatnya kompleks, samar, dan tidak lebih menarik daripada mengisi laporan pajak
  • Namun, berkat pekerjaan yang dilakukan Red Hat, penggunaan SELinux di RHEL sebagian besar menjadi transparan dan memberi manfaat keamanan nyata bagi pengguna

Pendekatan Debian terhadap AppArmor

  • Debian adalah inti komunitas open source yang terkenal karena stabilitasnya dan pustaka software yang luas
  • Namun, framework keamanan bawaannya masih sangat perlu ditingkatkan
  • Keputusan untuk mengaktifkan AppArmor secara default mulai Debian 10 adalah langkah positif untuk meningkatkan keamanan, tetapi penerapannya setengah hati di seluruh sistem sehingga masih kurang
  • Ketergantungan Debian pada AppArmor dan konfigurasi bawaannya menunjukkan adanya masalah sistematis dalam pendekatannya terhadap keamanan
  • AppArmor dapat memberikan keamanan yang kuat bila dikonfigurasi dengan benar, tetapi pengaturan bawaan Debian tidak memanfaatkan potensinya

Masalah AppArmor di Debian

  • Profil bawaan yang terbatas: Debian hanya hadir dengan sekumpulan profil AppArmor minimal sehingga banyak layanan penting tidak terlindungi
  • Sikap reaktif vs proaktif: model keamanan Debian sering bergantung pada pengguna untuk menerapkan kebijakan yang lebih ketat, alih-alih menyediakan konfigurasi aman secara default
  • Penerapan yang tidak konsisten: tidak seperti SELinux pada sistem Red Hat, AppArmor di Debian hanya diterapkan sebagian sehingga menimbulkan celah keamanan potensial
  • Kekurangan sumber daya: sebagai proyek yang digerakkan komunitas, Debian tidak memiliki sumber daya untuk mengembangkan dan memelihara kebijakan keamanan komprehensif yang setara dengan yang disediakan Red Hat

Menjalankan workload container melalui Docker di Debian

  • Menjalankan workload container melalui Docker di Debian sangat umum dilakukan
  • Docker secara otomatis membuat dan memuat profil AppArmor bawaan untuk container bernama docker-default
  • Sayangnya, ini bukan profil yang sangat kuat dari sisi keamanan dan terlalu permisif
  • Profil ini memang memberi perlindungan sampai tingkat tertentu, tetapi tetap membuka permukaan serangan yang signifikan

Perbedaan mendasar antara AppArmor dan SELinux

  • Perbedaan mendasar antara AppArmor dan SELinux terletak pada pendekatan mereka terhadap mandatory access control (MAC)
  • AppArmor bekerja dengan model berbasis path, sedangkan SELinux menggunakan sistem type enforcement yang jauh lebih kompleks
  • Perbedaan ini sangat menonjol terutama di lingkungan container
  • SELinux menerapkan type pada semua objek dalam sistem (file, proses, port, dan sebagainya)
  • Saat container dijalankan pada sistem RHEL yang mendukung SELinux, ia segera diberi type container_t, sebuah mekanisme kontrol akses yang ketat
  • Type container_t secara efektif membatasi container sehingga tidak dapat berinteraksi dengan objek yang tidak secara eksplisit diberi label untuk penggunaan container
  • SELinux tidak berhenti pada type enforcement, tetapi melangkah lebih jauh dengan menggunakan label multi-category security (MCS) untuk isolasi container
  • Label-label ini berfungsi sebagai lapisan pemisahan tambahan yang menjaga isolasi bahkan antar-container dengan type yang sama (container_t)
  • Setiap container menerima label MCS unik untuk menciptakan sandbox privat di dalam lingkungan container_t yang lebih luas

Pendekatan AppArmor

  • AppArmor tidak peduli pada type atau kategori, dan berfokus pada pembatasan kemampuan program tertentu berdasarkan profil yang telah ditentukan sebelumnya
  • Profil-profil ini menentukan file apa yang dapat diakses program dan tindakan apa yang boleh dilakukannya
  • Pendekatan ini lebih sederhana untuk diterapkan dan dipahami, tetapi tidak segranular atau sekonsisten type enforcement SELinux di seluruh sistem
  • Distribusi Linux arus utama tidak mendistribusikan profil AppArmor yang komprehensif untuk semua daemon umum yang berorientasi jaringan secara default

Dampak nyata

  • Dalam lingkungan SELinux, container yang telah dikompromikan menghadapi hambatan besar untuk mengakses atau memengaruhi sistem host maupun container lain berkat penghalang ganda berupa type enforcement dan label MCS
  • SELinux menawarkan isolasi yang lebih kuat, tetapi dengan konsekuensi kompleksitas yang lebih tinggi dan potensi overhead performa
  • AppArmor menawarkan model keamanan yang lebih sederhana dan mudah diakses, yang tetap bisa sangat efektif bila dikonfigurasi dengan benar
  • Red Hat telah berupaya membuat penggunaan SELinux dan container menjadi mulus dan mudah
  • Pada akhirnya, pilihan antara Debian dan Red Hat bukan semata pilihan antara pengaruh perusahaan dan pengembangan yang digerakkan komunitas
  • Ini juga merupakan pilihan antara sistem yang berasumsi semuanya akan baik-baik saja dan sistem yang bersiap menghadapi skenario terburuk
  • Di dunia yang sangat terhubung saat ini, sayangnya pesimisme adalah suatu keharusan

Opini GN⁺

  • Perubahan kebijakan distribusi kode sumber RHEL oleh Red Hat memang kontroversial, tetapi dari sudut pandang keamanan bisa jadi merupakan keputusan yang masuk akal
  • Dalam distribusi Linux enterprise, menyediakan fitur keamanan yang kuat seperti SELinux adalah hal yang esensial
  • Namun, perubahan kebijakan Red Hat dapat berdampak negatif pada ekosistem open source, dan peran distribusi berbasis komunitas seperti Debian kemungkinan akan menjadi semakin penting
  • Debian dikenal sebagai distribusi yang ramah pengguna dan fleksibel, tetapi penguatan fitur keamanan bawaan tetap diperlukan
  • AppArmor memang tidak sekuat SELinux, tetapi bila dikonfigurasi dengan tepat, ia bisa menjadi solusi keamanan yang efektif
  • Dalam jangka panjang, mungkin diperlukan pengembangan framework keamanan baru yang menggabungkan keunggulan SELinux dan AppArmor
  • Keamanan container adalah isu yang sangat penting di era cloud-native, sehingga semua distribusi perlu mencurahkan lebih banyak upaya pada bagian ini

2 komentar

 
koxel 2024-09-07

Memang benar AppArmor kurang ketat dibandingkan SELinux..
Tapi sulit dibilang itu berarti keamanannya lemah.
SELinux terlalu ketat, jadi saat menyiapkan server, hampir semuanya malah mematikan SELinux.
Dan untuk desktop, keamanan bukan perhatian utama SELinux.
Yang dibutuhkan adalah pembatasan yang diperlukan dari sisi UI atau pengalaman pengguna serta prosedur permintaan autentikasi yang tepat, dan ini adalah hal yang berbeda dari isolasi terhadap sumber daya seperti pada SELinux.
Karena itu, keamanan desktop, baik di kubu Red Hat maupun kubu Debian, semuanya berjalan berbasis polkit (policykit) yang distandardisasi di freedesktop.

 
GN⁺ 2024-09-06
Komentar Hacker News
  • Menonaktifkan SELinux adalah hal yang umum di berbagai lingkungan Red Hat
  • Alih-alih membahas lambatnya pembaruan Debian, saya jadi belajar tentang SELinux
  • Tidak adil menyimpulkan bahwa Debian secara umum kurang aman
  • Debian mungkin kurang aman untuk penggunaan container dan server
  • Bagi pengguna desktop, implementasi SELinux dari Red Hat tidak memberikan perlindungan yang besar
  • Saya tidak suka implikasi bahwa proyek yang digerakkan komunitas pada dasarnya kurang aman
  • Kekurangan sumber daya: Debian kekurangan sumber daya untuk mengembangkan dan memelihara kebijakan keamanan yang komprehensif dibandingkan dengan Red Hat
  • Container menyelesaikan masalah distribusi perangkat lunak, tetapi tidak menyelesaikan masalah keamanan
  • Container bisa menjadi mimpi buruk keamanan
  • Keputusan Red Hat ditafsirkan secara negatif di komunitas open source
  • Model Red Hat menyulitkan perusahaan kecil
  • Setelah IBM mengakuisisi Red Hat, ekosistem menjadi lebih sulit
  • Tidak adil mengkritik Debian karena SELinux tidak diaktifkan secara default
  • Linux kekurangan sumber daya untuk mengembangkan dan memelihara kebijakan keamanan yang komprehensif dibandingkan dengan Microsoft
  • Ada juga pengguna yang pindah ke Debian karena kompleksitas SELinux
  • Dasar-dasar SELinux bisa dipelajari lewat PDF SELinux Coloring Book
  • SELinux juga bisa diaktifkan di Debian
  • Saya belum pernah bertemu orang yang benar-benar antusias dengan SELinux
  • Saya belum pernah bertemu orang yang bisa menjelaskan kebijakan SELinux
  • Banyak orang menonaktifkan SELinux
  • Banyak orang menghindari distro Red Hat
  • Kompleksitas umumnya sangat buruk bagi keamanan
  • Bahkan sistem keamanan yang secara teori sempurna pun menjadi tidak aman jika sebagian besar pengguna menonaktifkannya
  • Gagasan mengganti kata sandi setiap bulan justru bisa memperburuk keamanan dalam praktik