Saya berpikir mungkin menguntungkan untuk memiliki pengguna dengan izin lebih tinggi daripada pengguna root.

Anda lihat, saya ingin menjaga semua kegiatan dan hampir semua hak pengguna root yang ada persis seperti sekarang.

Namun, saya ingin kemampuan untuk menolak hak istimewa untuk berakar pada kasus per kasus yang sangat terisolasi.

Salah satu keuntungan dari ini akan memungkinkan saya untuk mencegah file yang tidak diinginkan tertentu diinstal selama pembaruan. Ini hanyalah contoh dari satu kemungkinan keuntungan.

Karena pembaruan apt-get dijalankan oleh root atau dengan hak sudo, apt-get memiliki kemampuan untuk mengganti file-file tertentu yang tidak diinginkan selama pembaruan.

Jika saya bisa menolak hak istimewa ini untuk file-file khusus ini, saya bisa mengaturnya sebagai simlink ke /dev/nullatau mungkin memiliki file placeholder kosong yang bisa memiliki izin yang akan menolak file agar tidak diganti selama pembaruan.

Selain itu, saya tidak dapat membantu tetapi diingatkan tentang sebuah baris yang dikatakan dalam sebuah wawancara dengan salah satu pembuat Ubuntu ketika lelaki itu mengatakan sesuatu tentang bagaimana pengguna lebih mempercayai "kami" (merujuk pada pengembang Ubuntu) "karena kami memiliki root "Yang merupakan referensi bagaimana pembaruan sistem dilakukan dengan izin root.

Cukup mengubah prosedur instalasi untuk mengatakan mengatasi masalah ini sama sekali bukan yang saya tertarik di sini. Sekarang pikiran saya memiliki selera untuk gagasan memiliki kekuatan untuk menolak akses root, saya ingin mencari cara untuk membuat ini terjadi hanya demi melakukannya.

Saya hanya memikirkan hal ini dan belum menghabiskan waktu untuk ide sejauh ini dan saya cukup yakin bahwa ini bisa diatasi. Namun, saya ingin tahu apakah ini sudah dilakukan atau mungkin ini bukan ide atau konsep baru.

Pada dasarnya, sepertinya harus ada beberapa cara untuk memiliki pengguna super-super yang akan memiliki izin di luar sistem hanya dengan satu derajat.

Catatan: Meskipun saya merasa jawaban yang diterima paling cocok dengan kriteria, saya sangat suka jawabannya oleh @CR. juga.

Saya ingin membuat pengguna yang sebenarnya lebih tinggi di pohon (saya) tapi saya kira saya hanya perlu duduk satu hari ketika saya punya waktu untuk mencari tahu.

Selain itu, saya tidak mencoba memilih Ubuntu di sini; Saya tidak akan menggunakannya sebagai distro utama saya jika saya merasa negatif tentang hal itu.

"Pengguna" yang Anda inginkan disebut modul keamanan LSM: Linux. Yang paling terkenal adalah SELinux dan AppArmor.

Dengan ini Anda dapat mencegah binari tertentu (dan proses anak mereka) dari melakukan hal-hal tertentu (bahkan jika UID mereka root). Tetapi Anda dapat mengizinkan operasi ini gettydan proses anaknya sehingga Anda dapat melakukannya secara manual.

Anda salah memahami konsep rootpengguna.

Dalam bahasa Inggris biasa, rootada di "puncak pohon".

Bagaimana jika Anda memutuskan suatu hari untuk memiliki "pengguna super super", dan kemudian bulan depan, "pengguna super super super" (!). Seberapa jauh "naik" pohon yang ingin Anda tuju? Bagaimana Anda mengocok semua izin dan hierarki untuk membuatnya berfungsi? Siapa yang selalu di atas? Seseorang harus di atas, dan itu root. Akhir dari cerita.

Solusi yang diberikan di sini - termasuk AppArmor dan SELinux - tidak benar-benar mengubah ini. Mereka hanya memungkinkan kontrol butir yang lebih baik atas rootizin dan proses.

Bagi saya sepertinya proses pembaruan Anda tidak cocok untuk hasil yang diinginkan. Tapi itu sama sekali bukan kesalahan rootpengguna. Alih-alih hal-hal yang terlalu rumit, anggap rootsebagai pengguna izin tingkat tertinggi, dan yang lainnya, Anda harus bekerja ke bawah.

Saya tahu beberapa orang akan menandai ini, tetapi tidak ada level yang lebih tinggi dalam hirarki pengguna, dan semua solusi lain hanya memberikan kontrol yang sedikit berbeda tentang cara rootkerja izin. Tetapi mereka tidak membuat pengguna baru, dengan izin yang lebih tinggi.

Anda tidak dapat memiliki pengguna dengan "izin lebih banyak" daripada rootkarena rootmewakili tingkat izin setinggi mungkin. Menggunakan frasa seperti "lebih banyak kontrol daripada root" adalah sebuah kontradiksi - rootmemiliki kontrol penuh dan semua izin yang memungkinkan, jadi tidak ada yang dapat dilakukan di atasnya.

Jika Anda hanya ingin mencegah file atau direktori tidak diubah / dihapus maka atur saja flag yang tidak dapat diubah padanya.

chattr +i <file>

Bahkan root tidak akan dapat melakukan apa pun pada mereka kecuali flag dihapus. Dimungkinkan juga untuk menggunakan sistem container / namespace untuk mencegah akses root tapi itu sepertinya memerlukan banyak usaha keras untuk apa yang Anda butuhkan.

• Alih-alih memiliki pengguna super-super, Anda dapat membatasi root. lihat Apa saja cara berbeda untuk mengatur hak akses file dll di gnu / linux

• Ada juga AppArmor dan SELinux.

• Dan / Atau konfigurasikan sudo, sehingga Anda tidak memberikan hak root penuh. Anda dapat mengaturnya sehingga pengguna hanya dapat menjalankan perintah yang telah disepakati sebelumnya, dengan argumen yang telah disepakati sebelumnya.

• Anda juga dapat menggunakan virtualisasi untuk membatasi root:

  • cgroups, namespaces, chroot dll (buruh pelabuhan melakukan ini)
  • Xen
  • Virtualbox

• Lihat juga etckeeper: revisi alat ini mengontrol/etc direktori, dan menyinkronkannya dengan apt. Secara default tidak aman, instalasi jahat dapat menyabotnya, tetapi Anda juga bisa membuatnya untuk mendorong perubahan ke repositori cadangan berdinding api.

• Penggunaan kontrol revisi secara umum, dengan repositori cadangan berdinding api. Ini membantu dengan kerusakan tidak disengaja, disengaja dan kegagalan perangkat keras.

Repositori cadangan yang dipasangi firewall dapat berada di mesin yang berbeda, di internet, atau mesin virtual yang berbeda (atau sejumlah mesin virtual).

Untuk perangkat lunak seperti APT , yang dalam operasi normal memerlukan akses ke hampir semua sistem, pembatasan itu bermasalah. Bahkan jika Anda mencegahnya mengakses bagian-bagian tertentu dari sistem, kemungkinan besar ada lebih dari cukup kemungkinan bagi distributor jahat untuk bekerja. Misalnya dengan mengganti pustaka atau hanya biner atau menambahkan perubahan konfigurasi berbahaya, yang akhirnya akan digunakan oleh root tidak dibatasi.

Bergantung pada seberapa banyak Anda akan menempatkan batasan, beberapa skrip instalasi dapat diharapkan rusak.

Untuk cara membatasi aplikasi dan pengguna, Anda dapat menulis AppArmor atau kebijakan SELinux. Kebijakan seperti itu yang mana yang lebih didukung tergantung pada distribusi Anda: Berbasis Debian memiliki dukungan yang lebih baik untuk AppArmor sementara distribusi berbasis Fedora / RHEL memungkinkan SELinux secara default.

Baik AppArmor dan SELinux bekerja pada kebijakan daftar putih , yang berisi aturan untuk mengizinkan (atau menolak) tindakan tertentu. Kebijakan diterapkan pada proses di eksekutif , pengguna yang sama dapat dibatasi ketika kebijakan diterapkan pada proses mereka saat masuk. Kebijakan yang dipikirkan dengan baik tidak dapat dielakkan (jika bug kernel tidak dipertimbangkan). Proses terbatas yang berjalan sebagai root (uid 0) dibatasi oleh kebijakan yang dikonfigurasi dan tidak dapat mengubahnya kecuali diizinkan secara eksplisit dalam kebijakan tersebut.

Bahasa kebijakan AppArmor mendefinisikan aturan penolakan , yang dapat digunakan untuk membuat kebijakan daftar hitam . Tempat yang baik untuk memulai dengan AppArmor adalah halaman manual AppArmor , wiki , dan mencari konfigurasi yang ada pada distribusi Anda di/etc/apparmor.d/ .

Banyak bahan administrasi dan pengembangan SELinux disediakan dalam SELinux wiki . Kebijakan referensi SELinux di -host di github.

Saya tidak percaya tidak ada yang menyebutkan untuk menyematkan ...

Beberapa tahun yang lalu, Microsoft merilis tambalan yang memecahkan mesin Windows 10 dari berbicara dengan Pengendali Domain Samba NT4 lama kami. Ketika masalah ditemukan, kami menyematkan paket Samba agar tetap pada versi saat ini, dan aptmasih berfungsi dengan benar.

Debian Walkthrough lengkap menjelaskan proses dengan baik:

Di /etc/apt/preferences(atau file baru di bawah /etc/apt/preferences.d/), tambahkan beberapa teks untuk menentukan paket dan versi mana:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

Periksa dokumentasi untuk sintaks yang tepat, tetapi ini adalah cara cepat dan kotor kami menyematkan versi paket. Root bisa mem bypassnya, seperti yang biasa dilakukan root, tetapi ini memecahkan masalah manajer paket yang mencoba memutakhirkan paket secara otomatis pada Anda.

CATATAN: Jawaban ini dengan asumsi Anda memiliki masalah XY

Ini sebenarnya cukup sederhana.

Root adalah "pengguna super super" Anda

Buat akun yang disebut "admin" dan berikan dia semua izin root kecuali yang Anda tidak inginkan.

Kemudian buat pengguna bernama bob, dan biarkan dia "menjadi admin". Dengan menggunakan su atau bahkan sudo.

Sekarang Anda memiliki pengguna normal (bob) pengguna super yang dapat melakukan hal-hal admin (admin) dan pengguna super super (root).

Jika Anda ingin mengubah nama "root" menjadi sesuatu yang lain, Anda bahkan dapat melakukannya. Secara teknis, hanya id pengguna (0) yang penting.

Jika yang Anda inginkan hanya untuk mencegah file tertentu tidak diinstal, maka membatasi izin root bukanlah cara untuk melakukan hal ini. Perlu dicatat juga bahwa jawaban konvensional (file yang tidak dapat diubah atau LSM) tidak akan berfungsi untuk kasus penggunaan khusus Anda, seperti APT (dan sebagian besar manajer paket lainnya), akan memberikan jaminan jika mereka tidak dapat menginstal file.

Pertanyaan sesungguhnya yang ingin Anda tanyakan adalah:

Apakah ada cara untuk mencegah APT dari menginstal file tertentu?

Itu adalah sesuatu yang sangat berbeda dari apa yang Anda tanyakan di berbagai tingkatan.

Sekarang, sehubungan dengan pertanyaan itu, saya sendiri tidak 100% yakin, tetapi saya tahu sejumlah manajer paket lain memiliki opsi untuk mencegah instalasi file tertentu (misalnya, sistem Portage Gentoo memiliki opsi INSTALL_MASK= , yang sebenarnya menerima shell Pola pencocokan-gaya hal untuk tidak menginstal). Saya akan lebih dari berani bertaruh bahwa opsi seperti itu ada untuk APT (atau mungkin dpkg itu sendiri).

Letakkan salinan cadangan di tempat yang aman. Setelah menginstal / memperbarui, segera ganti file tertentu dari cadangan itu. Dengan demikian, tidak ada kesalahan untuk mengacaukan instalasi tetapi Anda masih mendapatkan kembali file yang ingin Anda simpan.

Bekerja dari drive yang terpasang

Perhatikan bahwa ini sebagian besar merupakan jawaban konseptual, tetapi saya pikir ini harus bekerja dan semangat dengan apa yang ingin Anda capai.

Biarkan sistem X menjadi sistem kerja Anda, dan sistem Y sistem lain yang Anda kendalikan

1. Pasang direktori dari Y sebagai drive di X
2. Siapkan hak sedemikian rupa sehingga pengguna root X memiliki hak untuk semua yang ada di drive terpasang ini, dengan beberapa pengecualian

Sekarang Anda memiliki 'root kerja' yang dapat melakukan hampir semua hal, dan Anda memiliki 'root super', akun root sebenarnya dari sistem Y, yang benar-benar dapat melakukan semuanya.

Anda dapat menjalankan hypervisor tipe-1 seperti Xen hypervisor & membuat hosting OS biasa Anda sebagai tamu tervirtualisasi. Hypervisor mengontrol OS tamu virtual pada tingkat "lebih dalam" dari root karena memiliki kontrol atas perangkat keras (virtual) tempat OS tamu berjalan.

Anda dapat memprogram hypervisor untuk memanipulasi OS tamu dengan berbagai cara, termasuk mengubah izin, membuat & menerapkan cadangan, mengaitkan perubahan atau instruksi tertentu di OS tamu untuk menyuntikkan fungsionalitas tambahan, validasi, dll. Itu akan menjadi cara yang valid dan berpotensi bermanfaat untuk mengimplementasikan sistem tipe unix dengan "pengguna" (sebenarnya fungsi dari hypervisor) untuk "melakukan hal-hal yang bahkan root tidak dapat melakukannya"

Namun saya merasakan bahwa pendekatan ini mungkin berlebihan

Lihatlah cgroups dan ruang nama Linux sebagai metode alternatif untuk mencapai jenis tujuan ini, serta alat-alat yang didasarkan pada mereka seperti Docker dan lxd .

Alat-alat ini memungkinkan Anda untuk, antara lain, membatasi bagian mana dari sistem file yang dapat dilihat oleh proses "root", membatasi proses mana yang terlihat, dan hanya memberikan kemampuan tertentu kepada pengguna "root".

UNINSTALL sudo

Bagaimana menguninstall sudodan symlink /bin/suke /bin/false? Pasangan itu dengan memastikan bahwa roottidak bisa masuk viassh dan Anda telah mengunci sistem.

Itu membuat root Super * Super User, dan semua orang di bawahnya.

Untuk file yang diganti selama pembaruan, jangan lakukan pembaruan apa pun. Lebih realistis lagi, ubah izin file ke 440atau lebih 444sehingga tidak dapat ditulis. Atau menempatkan mereka di repositori git sehingga jika mereka ditimpa, itu dapat dikembalikan.