Kami mengalami sedikit masalah di server. Kami ingin beberapa pengguna dapat melakukan mis sudodan menjadi root, tetapi dengan batasan bahwa pengguna tidak dapat mengubah kata sandi root. Artinya, jaminan bahwa kami masih bisa masuk ke server itu dan menjadi root tidak peduli apa yang akan dilakukan pengguna lain.

Apakah itu mungkin?

Kami ingin beberapa pengguna dapat melakukan mis sudodan menjadi root,

Nah, itulah masalahnya sudo dirancang untuk dipecahkan, sehingga bagian itu cukup mudah.

tetapi dengan batasan bahwa pengguna tidak dapat mengubah kata sandi root.

Anda dapat, seperti yang ditunjukkan SHW dalam komentar, mengonfigurasi sudo hanya mengizinkan tindakan tertentu untuk diambil sebagai root oleh pengguna tertentu. Artinya, Anda dapat mengizinkan user1 untuk melakukan sudo services apache2 restart, memungkinkan user2 untuk melakukan sudo reboottetapi tidak ada yang lain, sambil membiarkan administrator yang dipekerjakan sebagai sistem user3melakukan sudo -i. Ada howtos yang tersedia tentang cara mengatur sudo seperti itu, atau Anda dapat mencari (atau bertanya) di sini. Itu adalah masalah yang bisa dipecahkan.

Namun, pengguna yang telah diberikan kemampuan ke sudo -iatau sudoke dalam shell ( sudo bash, misalnya) dapat melakukan apa saja. Itu karena pada saat sudo meluncurkan shell, sudo sendiri sudah keluar dari gambar. Ini memberikan konteks keamanan pengguna yang berbeda (paling sering melakukan root), tetapi tidak memiliki suara dalam apa yang dilakukan aplikasi yang dieksekusi. Jika aplikasi itu pada gilirannya diluncurkan, passwd roottidak ada yang bisa dilakukan sudo. Perhatikan bahwa ini dapat dilakukan melalui aplikasi lain juga; sebagai contoh, banyak editor yang lebih maju menyediakan fasilitas untuk mengeksekusi perintah melalui shell, shell yang akan dieksekusi dengan uid efektif dari proses editor itu (yaitu, root).

Artinya, jaminan bahwa kami masih bisa masuk ke server itu dan menjadi root tidak peduli apa yang akan dilakukan pengguna lain.

Maaf; jika Anda benar-benar bermaksud "memastikan kami akan dapat masuk dan menggunakan sistem tidak peduli apa yang dilakukan seseorang dengan akses root", bahwa (untuk semua maksud dan tujuan) tidak dapat dilakukan. "Sudo rm / etc / passwd" atau "sudo chmod -x / bin / bash" yang cepat (atau apa pun yang menggunakan root shell) dan Anda cukup banyak disembunyikan. "Cukup banyak disembunyikan" yang berarti "Anda harus memulihkan dari cadangan dan berharap mereka tidak melakukan hal yang lebih buruk daripada selip jari". Anda dapat mengambil beberapa langkah untuk mengurangi risiko kecelakaan yang tidak disengaja yang mengarah ke sistem yang tidak dapat digunakan, tetapi Anda tidak dapat mencegah niat jahat dari menyebabkan masalah yang sangat serius hingga dan termasuk titik perlu membangun kembali sistem dari awal atau paling tidak dari yang diketahui. backup yang bagus.

Dengan memberikan akses root tanpa batas pada sistem ke pengguna, Anda percaya bahwa pengguna (termasuk perangkat lunak apa pun yang mereka pilih untuk mengeksekusi, bahkan sesuatu yang biasa-biasa saja seperti ls) untuk tidak memiliki niat jahat, dan untuk tidak mengacaukan secara tidak sengaja. Itulah sifat akses root.

Akses root terbatas melalui mis. Sudo sedikit lebih baik, tetapi Anda tetap harus berhati-hati untuk tidak membuka vektor serangan apa pun. Dan dengan akses root, ada banyak kemungkinan vektor serangan untuk serangan eskalasi hak istimewa.

Jika Anda tidak dapat mempercayai mereka dengan tingkat akses yang disyaratkan oleh root, Anda akan memerlukan konfigurasi sudo yang sangat ketat, atau untuk tidak memberikan pengguna akses root yang dipertanyakan sama sekali melalui segala cara, sudo atau lainnya.

Ini praktis tidak mungkin. Pertama-tama, jika Anda memberi mereka kekuatan untuk menjadi root , maka tidak ada yang dapat Anda lakukan untuk mencegah mereka melakukan apa pun. Dalam kasus penggunaan Anda, sudoharus digunakan untuk memberi pengguna Anda beberapa kekuatan root sambil membatasi orang lain tanpa membiarkan mereka menjadi root .

Dalam skenario Anda, Anda perlu membatasi akses ke sudan passwdperintah dan membuka akses ke hampir semua yang lain. Masalahnya adalah, tidak ada yang dapat Anda lakukan untuk mencegah pengguna Anda mengedit /etc/shadow(atau /etc/sudoersdalam hal ini) secara langsung dan memasukkan kata sandi pengganti root untuk membajak root. Dan ini hanya skenario "serangan" yang paling mudah. Sudoers dengan kekuatan tidak terbatas kecuali untuk satu atau dua perintah dapat mengatasi pembatasan untuk membajak akses root penuh.

Satu-satunya solusi, seperti yang disarankan oleh SHW dalam komentar adalah menggunakan sudountuk memberikan pengguna Anda akses ke serangkaian perintah sebagai gantinya.

Memperbarui

Mungkin ada cara untuk mencapai ini jika Anda menggunakan tiket Kerberos untuk otentikasi. Baca dokumen ini menjelaskan penggunaan .k5loginfile.

Saya mengutip bagian yang relevan:

Misalkan pengguna alice memiliki file .k5login di direktori rumahnya yang berisi baris berikut:
bob@FOOBAR.ORG
Ini akan memungkinkan bob untuk menggunakan aplikasi jaringan Kerberos, seperti ssh (1), untuk mengakses akun alice, menggunakan tiket Kerberos bob.
...
Perhatikan bahwa karena bob mempertahankan tiket Kerberos untuk kepala sekolahnya sendiri bob@FOOBAR.ORG, ia tidak akan memiliki hak istimewa yang memerlukan tiket alice, seperti akses root ke host situs mana pun, atau kemampuan untuk mengubah kata sandi alice.

Tapi saya mungkin salah. Saya masih mengarungi dokumentasi dan belum mencoba Kerberos sendiri.

Saya berasumsi Anda ingin memastikan Anda memiliki akses "admin darurat", bahkan jika administrator Anda yang sebenarnya kacau (tetapi selain itu, Anda sepenuhnya mempercayai administrator utama).

Pendekatan yang populer (meskipun sangat peretasan) adalah memiliki pengguna kedua denganuid=0 , umumnya dinamai toor(root backwards). Ini memiliki kata sandi yang berbeda, dan dapat berfungsi sebagai akses cadangan. Untuk menambahkan, Anda mungkin perlu mengedit /etc/passwddan /etc/shadow(menyalin rootgaris).

Semuanya aman-gagal, tetapi jika Anda hanya perlu melindungi terhadap "administrator utama" mengubah kata sandi tanpa pemberitahuan, maka itu akan berhasil. Mudah untuk menonaktifkan, dengan menghapus toorakun; jadi satu-satunya manfaat adalah memiliki kata sandi terpisah.

Atau, Anda mungkin ingin melihat mekanisme otentikasi alternatif, yaitu sshkunci libnss-extrausers,, LDAP dll.

Perhatikan bahwa admin masih bisa mengacaukannya. Misalnya dengan memblokir firewall.

Jika Anda ingin memiliki sistem yang sangat aman, pertimbangkan untuk menggunakan SELinux, di mana pengguna unix (mis. Root) juga datang dengan sebuah peran, yang bisa lebih berbutir halus. Anda mungkin ingin memberikan akses root admin Anda, tetapi hanya peran yang dibatasi (mis. Untuk hanya mengelola apache). Tetapi ini akan membutuhkan banyak upaya di pihak Anda untuk mengonfigurasi kebijakan dengan benar.

Inti dari root adalah memiliki perintah sistem yang tidak dibatasi. Anda bisa mengubahnya dengan SELinux (dulu ada situs demo di mana siapa pun bisa login sebagai root, tetapi kekuatannya lumpuh melalui sistem akses), tapi bukan itu intinya. Intinya adalah ini adalah solusi yang salah untuk masalah Anda.

Sekarang, Anda belum mengatakan apa masalah Anda, tetapi jika Anda tidak mempercayai pengguna ini untuk tidak menggunakan kata sandi root, mereka tidak memiliki bisnis untuk di-root. Jika mereka perlu mengelola server web, atau berbagai perangkat perangkat keras, atau drive warp atau apa pun, siapkan solusi untuk itu. Buat grup berdaya super, berikan semua akses yang dibutuhkan, dan tambahkan ke dalamnya. Jika mereka perlu melakukan panggilan sistem hanya root, tulis beberapa program setuid.

Tentu saja pengguna dengan akses semacam itu (dan sedikit pengetahuan) mungkin dapat dengan mudah meretas sistem, tetapi setidaknya Anda bekerja dengan model keamanan OS, bukan menentangnya.

PS. Ada banyak cara untuk mengatur akses root untuk diri sendiri tanpa kata sandi; untuk satu, jika Anda berada di /etc/sudoers(tanpa batasan) Anda hanya perlu kata sandi Anda sendiri untuk menjadi root, misalnya dengan sudo bash. Tetapi Anda tidak perlu pergi ke sana.

Mungkin dimungkinkan, setidaknya secara teori, untuk melakukan ini menggunakan SELinux . Ini memungkinkan Anda untuk mengatur aturan yang jauh lebih tepat tentang apa yang pengguna atau proses boleh atau tidak boleh dilakukan. Bahkan dengan SELinux, mungkin sulit untuk membuatnya mustahil bagi pengguna untuk mengubah kata sandi root, tetapi masih dapat melakukan apa pun yang perlu mereka lakukan.

Benar-benar itu tergantung pada apa yang harus dilakukan oleh pengguna yang tidak diizinkan untuk mengubah kata sandi root. Mungkin akan lebih mudah dan lebih aman untuk hanya mencari tahu apa itu, dan memberikan izin tersebut secara khusus menggunakan sudo.

Mungkin Anda harus mempertimbangkan untuk membiarkan pengguna memiliki akses root ke mesin virtual atau wadah LXC. Itu akan memungkinkan mereka untuk memiliki akses root penuh ke suatu sistem, tanpa membiarkan mereka mencegah Anda masuk ke host atau mengambil tindakan administratif.

Saya tidak tahu ini akan layak secara praktis tetapi ini adalah satu hack kotor:

1. tulis skrip / program pembungkus yang akan menyalin /etc/passwdfile ke lokasi lain, sebelum menelepon yang sebenarnyasudo
2. Izinkan pengguna normal untuk menggunakan sudo
3. Begitu dia menyelesaikan tugasnya, atau ketika dia keluar dari sudo, kembalikan /etc/passwdfile tersebut

Saya tahu, ada banyak hal plus-minus yang harus Anda pertimbangkan untuk mencapai ini. Bagaimanapun, ini adalah hack yang kotor

Pernyataan yang sudohanya untuk memberikan root dan tidak ada perlindungan setelah itu jelas-jelas salah.

Anda gunakan visudountuk memodifikasi file sudoers. Berikut ini contoh baris:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroadalah nama pengguna yang kami beri izin. Letakkan a %di depan untuk membuatnya berlaku untuk grup.
• ALLadalah nama untuk aturan ini. Sudoers dapat melakukan lebih dari sekedar memberikan izin global. Di situlah menjadi rumit sekalipun.
• = tidak perlu penjelasan
• ALL:ALLdibaca sebagai (who_to_run_it_as: what_group_to_run_it_as). Dengan cara ini Anda dapat mengizinkan menjalankan perintah, tetapi hanya dalam konteks pengguna atau grup tertentu.
• NOPASSWD: mengatakannya untuk mematikan prompt kata sandi.
• /path/to/command memungkinkan Anda menentukan perintah spesifik path_to_commmand, another_command

Yang perlu diingat adalah bahwa sementara sudosebagian besar digunakan oleh pengguna rumahan untuk meningkatkan hak akses root, itu bisa dan digunakan untuk mengontrol akses ke perintah tertentu dengan cara yang jauh lebih terperinci.

Referensi

• dari jawaban saya yang lain di sini

(Saya tidak tahu ubuntu, tetapi harus mirip dengan Fedora / Red-Hat)
Satu-satunya hal yang dapat saya bayangkan membatasi akses untuk mengubah kata sandi root adalah tidak memberikan akses root penuh, mungkin dengan sudo, atau menggunakan SElinux untuk membatasi akses ke file kata sandi ... tapi saya tidak akan mempercayai dengan banyak akses karena root pada umumnya memiliki akses tidak terbatas dan dapat memperbarui SElinux, atau mengubah nama file kata sandi, atau menjalankan beberapa program yang sudah disiapkan sebelumnya untuk mengubah kata sandi.

Jika Anda tidak cukup mempercayai mereka untuk tidak mengubah kata sandi, Anda mungkin seharusnya tidak memberi mereka akses root. Kalau tidak, saya kira Anda mencoba menghindari kecelakaan.

Jika Anda hanya mencoba melindungi akses Anda untuk melakukan root, aturlah sebuah program yang dapat mengembalikan kata sandi root, jadi meskipun itu diubah, program tersebut dapat dipulihkan dengan akses minimal. (Sudo melakukannya dengan baik pada miliknya sendiri)

Kebutuhan Anda adalah:

Kami mengalami sedikit masalah pada server [...] yaitu, jaminan bahwa kami masih dapat masuk ke server itu dan menjadi root tidak peduli apa yang akan dilakukan pengguna lain.

Dari pertanyaan Anda, seolah-olah Anda tidak menghadapi pengguna jahat acak yang bermaksud menghancurkan sistem Anda, tetapi sebaliknya memiliki pengguna semi tepercaya yang dapat menyebabkan kerusakan sekarang dan kemudian (siswa mungkin?). Saran saya mengatasi situasi itu, bukan serangan habis-habisan oleh pengguna jahat.

1. Jalankan server di dalam lingkungan virtual. Anda dapat memasang sistem file server dan mengganti file yang diubah dengan versi yang dikenal baik. Bergantung pada kemungkinan kerusakan yang Anda antisipasi, Anda dapat mengambil snapshot dari semua direktori penting (/ bin, / sbin, / etc, / usr, / var, dll.) Dan memperluas snapshot untuk menimpa file yang rusak sambil meninggalkan sisa dari sistem utuh.

2. Jalankan sistem hanya-baca, mis. Dari DVD-R. Jika Anda dapat hidup dengan sebagian besar sistem menjadi statis hingga reboot berikutnya, ini adalah opsi yang baik. Anda juga bisa menggunakan backing store read-only dengan lingkungan virtual atau memuat sistem basis melalui jaringan, membuat perubahan antar reboot jauh lebih mudah daripada menulis DVD-R baru.

3. Modul kernel. Linux Security Modules (LSM) dari kernel menyediakan dasar untuk membuat modul yang aman. LSM digunakan oleh SELinux, tetapi juga digunakan oleh sejumlah sistem yang kurang dikenal dan lebih sederhana, seperti Smack, TOMOYO, dan AppArmor. Artikel ini memiliki ikhtisar opsi yang bagus. Peluangnya adalah salah satu yang dapat dikonfigurasikan out-of-the-box untuk mencegah akses tulis ke / etc / passwd, / etc / shadow, atau file lain yang Anda inginkan, bahkan oleh root.

4. Ide yang sama dengan # 1, tetapi ketika server tidak berada dalam lingkungan virtual. Anda bisa memasukkan server-load ke dalam sistem read-only seperti live CD, yang secara otomatis akan me-mount sistem file server dan menimpa sistem basis pada setiap boot dengan salinan yang dikenal baik. OS read-only kemudian akan boot ke OS utama.

5. Sekali lagi, dengan asumsi ini adalah pengguna semi tepercaya yang bertanggung jawab kepada atasan (guru / bos), jawaban terbaik mungkin adalah Audit Linux . Dengan cara ini Anda akan mengetahui setiap tindakan yang relevan dengan keamanan yang diambil dan siapa yang mengambilnya (Anda akan tahu siapa yang mengambilnya karena meskipun semua pengguna berbagi akun root, mereka akan sudo'ed dari akun pengguna mereka terlebih dahulu). Bahkan Anda mungkin dapat mengurai log audit secara realtime dan mengganti file yang rusak. / etc / shadow ditimpa? Tidak masalah, hanya meminta server pemantauan langsung menggantinya dengan versi yang dikenal baik.

Teknologi lain yang mungkin ingin Anda selidiki berdasarkan kebutuhan Anda:

• Arsitektur Pengukuran Integritas Linux / Modul Verifikasi Diperluas (IMA / EVM), dan
• Modul Platform Tepercaya (TPM).

Untuk melengkapi jawaban yang lain, saya akan berasumsi bahwa skenarionya adalah Anda merasa kehilangan kontrol root situasi yang langka, dan bahwa dalam kasus-kasus tersebut reboot server diperbolehkan. (Lagi pula, jika Anda yakin mesin itu telah dikompromikan, Anda tetap ingin membuatnya offline.)

Keuntungan besar dari ini adalah tidak ada yang perlu dikonfigurasi. Pertanyaan Anda menjadi: " Saya lupa kata sandi root, bagaimana saya kembali? " Dan jawabannya adalah me-reboot, dan memilih mode single-user ketika mesin muncul. Itu memberi Anda shell root tanpa perlu tahu kata sandi. Pada saat itu Anda dapat mengatur kata sandi baru. (Serta pergi dan memperbaiki kerusakan ...)

Jika Anda mengkloning server Anda menjadi VM (seperti VirtualBox ), Anda dapat memberikan akses root tanpa batas kepada orang-orang dan masih menjamin bahwa Anda akan selalu memiliki akses langsung ke partisi sistem operasi tamu, dan oleh karena itu mempertahankan kontrol akhir atas /etc/passwddan sejenisnya, karena Anda akan memiliki root pada sistem host.

Tentu saja, memberikan akses root tanpa batas mungkin masih bukan solusi yang tepat: jika keamanan data merupakan masalah atau tanggung jawab Anda, Anda tidak dapat memberikan akses root.

Persyaratan ini tidak memungkinkan secara teknis. Seperti telah dikomentari dengan fasih, memberikan hak tanpa batas atau bahkan lebih terbatas sudokepada pengguna berarti Anda mempercayai pengguna itu. Seseorang yang memiliki niat jahat dan kemampuan teknis serta ketekunan yang cukup dapat melewati segala rintangan yang ada.

Namun, dengan asumsi Anda dapat memercayai pengguna Anda untuk tidak berkeinginan jahat, Anda dapat membuat pembatasan pada kata sandi mengubah masalah kebijakan . Anda dapat membuat pembungkus untuk passwdprogram yang akan mengingatkan mereka "tolong jangan ubah kata sandi root". Ini mengasumsikan sumber masalahnya adalah bahwa pengguna yang mengubah kata sandi root melakukannya karena kesalahpahaman (seperti mungkin berpikir mereka mengubah kata sandi mereka sendiri setelah selesai sudo bash).

Dalam keadaan khusus (jarang), jika lengkap kepercayaan tidak mungkin dan tidak mungkin untuk memecahkan sudoakses ke potongan cukup tapi cukup aman, Anda mungkin mempertimbangkan membangun sanksi organisasi terhadap perubahan password (atau bentuk tertentu lainnya dari sistem sabotase), mengatur pemantauan sumber daya kritis sehingga tidak mudah untuk tidak terdeteksi untuk menyiasati kebijakan yang ditetapkan - dan menjadi publik dan transparan tentang aturan penggunaan dan pemantauan.

Aspek pemantauan dan penemuan adalah masalah teknis yang sulit yang didapat dari pertanyaan lain jika Anda memilih untuk menempuh jalan itu. Sepertinya saya perlu melakukannya

1. mendeteksi ketika pengguna mengubah identitas untuk melakukan root dan melacak setiap proses yang dibuat;
2. log kreasi proses sejak saat itu untuk melihat siapa pengguna asli yang bertanggung jawab untuk setiap proses, dan menggunakan host jarak jauh di mana pengguna setengah tepercaya tidak memiliki akses untuk mengirim log;
3. menggunakan semacam pelacakan sistem untuk mencatat apa yang terjadi dan kemudian dapat menemukan siapa yang berada di balik pelanggaran kebijakan.

Setidaknya kita perlu mencatat pembukaan file selain dari set file yang aman untuk menulis, membuat proses exec(), dan tentu saja setiap upaya untuk mengubah jaringan.

Implementasi dapat dilakukan dengan libc yang dimodifikasi atau penelusuran panggilan sistem (jauh lebih baik).

Tentu saja, tidak mungkin untuk membuat penelusuran dan penebangan seperti itu bekerja 100% dengan benar, tidak mudah untuk diimplementasikan, dan juga membutuhkan sumber daya tambahan untuk beroperasi. Ini tidak akan menghentikan perubahan kata sandi atau gangguan sistem yang tidak disukai lainnya, tetapi akan memungkinkan (lebih mungkin) untuk menemukan pengguna yang bersalah atau setidaknya menciptakan ilusi bahwa ada pemantauan dan membuatnya kurang mengundang bagi beberapa pengguna yang berpikiran jahat (tetapi beberapa peretas pencinta masalah yang melihat kesia-siaan mendasar dari langkah-langkah teknis yang diberlakukan mungkin merasa terdorong untuk menerima tantangan dan mencoba menghindari sistem hanya untuk bersenang-senang).

Pertanyaan yang dirumuskan semula tidak berguna. Sepertinya tujuan utama adalah "masih memiliki login" sehingga berbicara tentang beberapa masuk darurat yang tetap berfungsi bahkan dengan akses root yang diberikan kepada orang lain. Ceria untuk Anony-Mousse yang pertama kali mencatatnya secara eksplisit.

Masalahnya adalah: Jika pemilik memiliki akses fisik ke kotak, ia dapat dengan mudah memulihkan akses logis ke sistem (asalkan masih hidup :). Jika tidak - menjaga kata sandi root tidak akan menyelamatkan dari mis. Sshd down atau pengaturan jaringan yang buruk, maka sistem tetap tidak dapat diakses.

Topik tentang bagaimana mencegah sistem dari kerusakan oleh seseorang dengan hak administratif tampaknya terlalu luas untuk disesuaikan dengan format pertanyaan SE.

Berbicara tentang solusi masuk darurat jarak jauh, cara terbaik adalah IPMI (saya pikir) jika tersedia. Pemilik sistem dapat meng-atache virtual drive kapan saja, boot darinya dan diproses dengan pemulihan sistem.

Jika IPMI tidak tersedia, teknologi virtualisasi yang sesuai dapat digunakan, seperti yang telah diusulkan di atas.

Anda dapat membatasi akses ke sudo dalam /etc/sudoersfile Anda

Untuk sepenuhnya menjelaskan sintaks dari / etc / sudoers, kami akan menggunakan aturan sampel dan memecah setiap kolom:

jorge  ALL=(root) /usr/bin/find, /bin/rm

Kolom pertama menentukan pengguna atau grup yang menerapkan aturan sudo ini. Dalam hal ini, itu adalah jorge pengguna. Jika kata dalam kolom ini didahului dengan simbol%, kata ini menunjuk nilai ini sebagai grup alih-alih pengguna, karena sistem dapat memiliki pengguna dan grup dengan nama yang sama.

Nilai kedua (ALL) mendefinisikan host apa yang diterapkan aturan sudo ini. Kolom ini paling berguna ketika Anda menggunakan lingkungan sudo di beberapa sistem. Untuk sistem Ubuntu desktop, atau sistem di mana Anda tidak berencana untuk menyebarkan peran sudo ke beberapa sistem, Anda dapat merasa bebas untuk membiarkan nilai ini disetel ke ALL, yang merupakan wildcard yang cocok dengan semua host.

Nilai ketiga diatur dalam tanda kurung dan mendefinisikan apa pengguna atau pengguna pengguna di kolom pertama dapat mengeksekusi perintah sebagai. Nilai ini disetel ke root, yang berarti jorge akan diizinkan untuk mengeksekusi perintah yang ditentukan di kolom terakhir sebagai pengguna root. Nilai ini juga dapat diatur ke wildcard ALL, yang akan memungkinkan jorge untuk menjalankan perintah sebagai pengguna di sistem.

Nilai terakhir (/ usr / bin / find, / bin / rm) adalah daftar perintah yang dipisahkan koma, pengguna di kolom pertama dapat dijalankan sebagai pengguna di kolom ketiga. Dalam hal ini, kami mengizinkan jorge untuk menjalankan find dan rm sebagai root. Nilai ini juga dapat diatur ke wildcard ALL, yang akan memungkinkan jorge untuk menjalankan semua perintah pada sistem sebagai root.

Dengan mengingat hal ini, Anda dapat mengizinkan perintah X dengan cara yang dibatasi koma dan selama Anda tidak menambahkannya passwd, Anda harus baik-baik saja.

Tidak ada 1/2 root :) Setelah Anda memberikan privilege root, mereka dapat melakukan apa pun yang mereka inginkan. Atau Anda dapat menggunakan sudo untuk menjalankan bash shell terbatas atau menjalankan rbash tanpa hak akses root.

Jika Anda ingin memiliki mekanisme yang gagal untuk login ke server sebagai root, Anda dapat membuat pengguna lain dengan uid=0atau membuat cron sederhana yang akan mengatur ulang kata sandi root secara berkala.

Coba tambahkan grup roda daripada menggunakan sudo. sudo memungkinkan pengguna untuk mengeksekusi seolah-olah mereka root yang artinya tidak ada bedanya dengan menjalankan:

su -

menjadi root. Root uid = 0; roda uid = 10. Orang-orang menggunakan nama tetapi OS menggunakan uid. Perintah tertentu tidak dapat dijalankan oleh anggota grup wheel. (Jika Anda menggunakan roda jangan salah menambahkan root sebagai anggota grup roda). Lihatlah dokumentasi Red Hat jika Anda tidak tahu apa itu roda.

Pilihan lain adalah menggunakan kunci ssh daripada kata sandi. Dengan asumsi Anda dapat yakin orang-orang yang menggunakan sudo tidak menambahkan kunci publik mereka ke file ~ / .ssh / yang diotorisasi ini dapat mengatasi masalah perubahan kata sandi root karena kata sandi root secara efektif diabaikan.

Jika Anda lebih memilih untuk memperluas kepercayaan kepada pengguna ini (untuk tidak menambahkan kunci publik mereka sendiri) coba gunakan atribut file yang diperluas dan menggunakan bit Immutable. Setelah membuat file ~ / .ssh / yang diotorisasi, dan setelah mengkonfigurasi / etc / ssh / sshd_config dan / etc / ssh / ssh_config sesuka Anda, setel bit Immutable. Tentu, ada cara untuk mengacaukannya juga - tidak ada yang sempurna.

Dalam sistem apa pun, orang dalam adalah risiko tertinggi. Orang yang menjalankan pertunjukan berada di bagian atas tumpukan. Pikiran terkait berkaitan dengan kontrak. Pengacara akan memberi tahu Anda, "Jangan pernah berbisnis dengan seseorang yang Anda perlukan kontrak untuk berbisnis dengan". Akal sehat memberi tahu kita, "Jangan pernah melakukan bisnis tanpa kontrak". Ketika Anda menemukan seseorang yang cukup Anda percayai untuk berbisnis, tulis kontrak berdasarkan kebutuhan masing-masing.

Semua jawaban yang diajukan, termasuk jawaban saya, gagal mengatasi akses fisik. Siapa pun yang memilikinya, memiliki kendali. Jika bukan Anda maka kemungkinan ada cara bagi Anda untuk mendapatkan orang yang melakukannya untuk mengakses mesin secara fisik jika seseorang menemukan cara untuk mencegah Anda masuk, atau jika mereka menemukan cara untuk masuk bahkan setelah Anda Sudah berusaha untuk mencegah hal itu terjadi. Tentu saja, jika Anda memiliki akses fisik daripada mungkin tidak ada kebutuhan untuk hal-hal ini meskipun menerapkan pasangan harus tetap dipertimbangkan, jika Anda tertarik untuk TIDAK merasa tidak nyaman.

-John Crout

Salah satu caranya adalah memastikan hal /etcitu tidak dapat ditulis. Oleh siapa pun, selama mungkin ada sudoersekitar.

Itu bisa dilakukan dengan memasangnya di jaringan dan memastikan di sisi lain bahwa perangkat tidak dapat ditulis.

Itu bisa dilakukan dengan menggunakan perangkat lokal yang mencegah akses tulis ke sana. (Cari write blockerperangkat keras)

Bagian yang penting adalah bahwa pembatasan harus diterapkan di luar konsep root dari mesin itu. Seorang peretas yang kreatif akan menemukan jalannya di sekitar semua hambatan yang Anda tempatkan di lingkungan yang bisa ia kendalikan. Jadi jika root dapat mengubah kata sandi, maka dapat juga a sudoer.

Untuk memastikan bahwa pengguna juga tidak dapat mengacaukan kemampuan login Anda, Anda harus sudah menginstal read-only /bindan /sbin.

Dan Anda harus memiliki skrip yang secara berkala mengembalikan koneksi jaringan.

(Sebagai sidenote: Jika Anda mengizinkan sudoer hanya seperangkat perintah yang sangat terbatas dan untuk masing-masingnya memastikan bahwa mereka tidak dapat keluar darinya / menggantinya, dll., Maka Anda dapat mencegahnya saat memiliki tulisan /etc..)