(kebanyakan) orang tidak menyuntikkan kerentanan dengan sengaja, itu terjadi secara tidak sengaja. Ketika volume kode meningkat, jumlah cacat meningkat. Namun bukan hanya ukurannya - jumlah bug bertambah dengan kompleksitas kode dan meningkat lebih cepat dari linear. Jadi lebih banyak kode adalah berita buruk untuk keamanan.
Permukaan serangan systemd jauh lebih besar daripada initd - konfigurasi default memiliki banyak antarmuka.
Gangguan besar bagi saya adalah filosofi desain; maksudnya adalah agar systemd menyediakan cara yang lebih terpadu bagi distributor untuk mengintegrasikan layanan. Tapi ini berarti menghilangkan kendali atas sistem dari admin sistem (di atas dampak penggantian sistem ekosistem yang kompleks tetapi dipahami dengan baik). Itu sengaja membuat sulit atau tidak mungkin untuk mencapai hal yang dapat dilakukan dengan initd (perhatikan bahwa ada banyak opsi untuk manajer layanan yang berjalan di bawah initd - djb daemontools, pemula, initng, rund, procd, openrc.... Sebagian besar menyelesaikan masalah paralelisasi / ketergantungan yang membatasi sistem init sysv rc).
Banyak logika start up sistem unix diimplementasikan dalam skrip shell. Ini membuatnya lebih mudah untuk tidak hanya merekayasa balik operasi tetapi juga untuk memperlengkapi dan memperluas kemampuan. Systemd memindahkan lebih banyak logika ke dalam biner dan lebih bergantung pada kompleks dan didokumentasikan dengan buruk konfigurasi.
Kombinasi dari sengaja mengurangi tingkat kontrol oleh administrator sistem dan kegagalan untuk mendukung administrator sistem dalam tugasnya membuat mereka lebih sulit untuk melakukan pekerjaannya - yang mencakup jaminan keamanan sistem.
Konsekuensi lebih lanjut dari semua kerumitan ini di PID 1 berarti Anda harus mem-boot ulang sistem Anda lebih sering. Selain berdampak pada ketersediaan, hal ini juga berarti memindahkan sistem Anda melalui serangkaian status sementara - yang dapat mengekspos kerentanan untuk sementara yang sulit dideteksi pada sistem homeostatis. Menggunakan daemon-reexec untuk mengatasinya membawa serangkaian masalah baru.
Model kebajikan-diktator-untuk-kehidupan tampaknya bekerja dengan baik untuk kernel linux, tetapi bukan itu cara industri open source lainnya beroperasi. Memang mungkin pengecualian yang membuktikan aturan - bahwa open source berfungsi karena tidak ada yang bertanggung jawab, meskipun tidak ada yang bertanggung jawab. Systemd mengambil kendali atas banyak fungsionalitas dalam sistem linux, namun beroperasi sebagai komunitas yang relatif kecil. Dan sesuai dengan penghargaan pwnie, tampaknya agak melihat ke dalam:tidak ada banyak perhatian pada kode:tidak ada yang mendengarkan ketika muncul kekhawatiran tentang kode tersebut.
Systemd sebenarnya adalah kumpulan dari beberapa bagian, dan agar perbandingannya masuk akal, Anda harus membandingkan bagian-bagian yang benar-benar sesuai satu sama lain.
Pertama mari kita lihat init SysV:Ini adalah program yang sangat kecil yang dijalankan sebagai proses pertama setelah boot yang melakukan beberapa pengaturan yang sangat mendasar, lalu membaca file konfigurasi (/etc/inittab ) dan memulai satu atau lebih program yang dikonfigurasikan di dalamnya, secara opsional memulai ulang program saat keluar. Itu juga membuka beberapa saluran komunikasi (/dev/initctl , penangan sinyal) yang memungkinkan untuk mengubah runlevel saat ini, perubahan yang akan mengakibatkan beberapa program lain dijalankan, sekali lagi seperti yang dikonfigurasikan dalam /etc/inittab .
Dan itu saja. Jelas, ini tidak memiliki permukaan serangan yang besar, hanya karena hampir tidak melakukan apa-apa. Di sisi lain, semua hal lain yang diperlukan untuk benar-benar mengelola sistem tipikal didelegasikan ke program eksternal:cara memulai dan menghentikan layanan tertentu (mis. server web, database, jaringan...), ketergantungan antar layanan (mis. memulai database terlebih dahulu , hanya kemudian server web), pemantauan yang lebih kompleks (fungsi pengawas), penghapusan hak istimewa dan kotak pasir, aktivasi layanan sesuai permintaan (mis. inetd), pemasangan sistem file, ... Systemd mengintegrasikan banyak fungsi ini dan karenanya lebih kompleks.
Sekarang, mengintegrasikan hal-hal ini di tempat sentral memiliki potensi besar untuk mengurangi kompleksitas dan kerapuhan secara keseluruhan dan dengan demikian membuat sistem lebih aman. Ambil berbagai fitur "kotak pasir", termasuk menjatuhkan hak istimewa, membatasi akses ke direktori tertentu, direktori temp pribadi, mengatur ruang nama terpisah, isolasi jaringan ... Untuk systemd, ini cukup mudah diterapkan sebagai bagian dari pengaturan lingkungan layanan, yang mana - sebagai manajer layanan - harus tetap melakukannya. Sebaliknya, dengan init SysV, program terpisah harus digunakan; dalam praktiknya ini akan menjadi sekumpulan skrip shell, atau akan diintegrasikan dalam layanan individual, sehingga menyebarkan kode "berisiko" ke lebih banyak tempat.
Selain itu, systemd memberi administrator sistem sarana untuk mengatur fitur-fitur ini dengan mudah (beberapa baris dalam file konfigurasi), membebaskan mereka dari keharusan mengimplementasikannya sendiri (yang dalam beberapa kasus bahkan dapat melibatkan modifikasi dan kompilasi ulang layanan!). Tentu saja, dalam praktiknya ini berarti mereka tidak digunakan sama sekali. Dari sudut pandang keamanan, format konfigurasi gaya ini juga merupakan keunggulan dibandingkan skrip shell turing-complete yang digunakan dengan init SysV.
Adapun model pengembangan di belakang systemd:Saya melihat ini sebagai keuntungan dibandingkan dengan alternatifnya, karena ada satu tempat sentral di mana pengembangan (dan pengujian ekstensif!) Terjadi, yang berbeda dengan campuran sebelumnya dari sebagian besar kode khusus distribusi. Bahkan inti init SysV sendiri berbeda di antara distribusi, karena hulunya dapat dianggap mati. Dan bertentangan dengan apa yang dikatakan orang lain, systemd upstream sebenarnya sangat responsif dan terbuka untuk permintaan perubahan yang wajar.
Yang mengatakan, saya dapat melihat satu situasi di mana segalanya berbeda, yaitu ketika fitur yang disediakan oleh systemd tidak diperlukan, misalnya jika Anda ingin membangun router atau gateway jaringan sederhana di mana rangkaian layanan yang diperlukan diketahui sebelumnya dan tidak akan pernah berubah. Bahkan di sana, Anda mungkin ingin memanfaatkan fitur kotak pasir yang mudah digunakan, dan ini adalah kasus khusus yang tidak berlaku untuk sebagian besar sistem.