Saya sedang menyiapkan mesin Ubuntu (10.10) yang akan digunakan oleh beberapa orang. Ini adalah mesin bersama di kantor kecil. Peran utamanya adalah hosting mesin virtual dengan VirtualBox dan melayani file dengan Samba.
Untuk Samba, beberapa akun pengguna perlu disiapkan sehingga berbagai orang dapat terhubung ke saham Samba dari workstation mereka sendiri. Namun, ada juga akun yang didedikasikan untuk hanya menjalankan mesin virtual, yang akan digunakan banyak orang. Kadang-kadang orang mencoba melakukan hal-hal dengan akun ini yang memerlukan hak istimewa tinggi - ini menyebabkan dialog "tolong masukkan kata sandi pengguna administratif" Gnome muncul. Namun, dialog ini meminta kata sandi saya - ketika saya mengatur mesin, akun saya adalah akun pertama yang dibuat, jadi sepertinya saya berasumsi bahwa saya adalah satu-satunya pengguna yang memberikan kekuatan sudo.
Saya ingin menunjuk pengguna lain sebagai "administrator resor pertama," untuk berbicara, dan itu tidak bisa menjadi pengguna akun bersama, karena semua orang harus mengetahui kata sandi akun itu, jadi saya ingin hak-hak istimewanya terbatas. Itu bukan akun saya, karena saya tidak bisa memberi tahu orang lain kata sandi saya, dan saya tidak akan cukup sering hadir di situs untuk memasukkannya sendiri. Namun, ada seseorang yang dapat melakukan ini secara langsung, jadi saya menambahkannya /etc/sudoers
. Bagaimana saya bisa memberi tahu Ubuntu bahwa ketika perlu meningkatkan hak istimewa untuk sesuatu, ia harus meminta akun mereka terlebih dahulu?
Untuk meringkas:
- Akun di mesin: Alice, Bob, Carol, Dave, Eliza.
- Ketika Ubuntu diinstal, Alice adalah pengguna pertama, ditambahkan selama proses instalasi.
- "Dave" sebenarnya adalah akun yang banyak digunakan orang, yang tidak bisa masuk
/etc/sudoers
karena kata sandinya adalah pengetahuan umum. - Bob telah ditetapkan menjadi akun "Administratif" di Gnome dan dimasukkan dengan benar
/etc/sudoers
- Bob adalah bos di kantor ini. - Ketika tindakan yang membutuhkan hak istimewa yang ditingkatkan dicoba saat masuk sebagai Bob, Carol, Eliza, atau Dave, sistem harus meminta kredensial Bob.
- Ketika tindakan yang memerlukan hak istimewa yang ditingkatkan dicoba saat masuk sebagai Alice, sistem harus meminta kredensial Alice (meskipun Alice adalah semacam sysadmin buckaroo dan memiliki kebiasaan menggunakan
su -
untuk melakukan tugas admin yang diperluas).
Perubahan konfigurasi apa yang harus saya lakukan untuk mewujudkan kondisi yang diinginkan di sini?
sumber
sudoers
file yang sama , Anda dapat memeriksa halaman manualnya untuk info lebih lanjut.sudoers
: ini bukan pilihan pertama karena masalah keamanan. Juga lihat jawaban enzotib - bagian dari masalahnya adalah kebingungan antarasudo
dan PolicyKit.Jawaban:
Pertama-tama biarkan untuk menunjukkan bahwa tindakan istimewa diizinkan untuk pengguna non-root melalui dua mekanisme berbeda.
sudo
PolicyKit
Yang pertama digunakan ketika Anda secara eksplisit menjalankan perintah dengan
sudo
atau item menu yang perintahnya dibungkusgksu
(seperti Synaptic Package Manager ).Dalam hal ini kata sandi yang diperlukan adalah kata sandi dari pengguna yang memanggil, biasanya pengguna yang masuk.
Yang kedua digunakan ketika aplikasi PolicyKit-aware mencoba melakukan tindakan istimewa. Dalam kasus seperti itu, aplikasi bertanya kepada Otoritas Lokal PolicyKit (melalui D-Bus) jika tindakan dapat dijalankan. Otoritas Lokal kemudian, melalui Agen Otentikasi, meminta pengguna aktif untuk membuktikan identitasnya. Jendela dialognya seperti berikut (sayangnya dengan teks dalam bahasa Italia :)
Anda dapat mengidentifikasi PolicyKit dari segitiga hitam kecil dan Rincian label . Seperti yang dapat Anda lihat, jika lebih dari satu pengguna dalam
admin
grup, Anda dapat memilih dari daftar pengguna mana yang akan digunakan untuk otentikasi.Mengingat semua ini, keduanya
sudo
dan PolicyKit jauh lebih rumit, sehubungan dengan konfigurasi yang dapat dicapai: Anda dapat mengonfigurasi tindakan yang dapat dieksekusi tanpa kata sandi, hanya dijalankan oleh pengguna atau grup tertentu, dll.Datang ke pertanyaan Anda, ketika mekanisme yang digunakan oleh aplikasi adalah PolicyKit, terlepas dari pengguna yang masuk saat ini, kata sandi yang diperlukan adalah Bob atau Alice (satu-satunya dua pengguna admin, jika saya mengerti dengan benar), dan Anda dapat mengubah dari daftar pengguna mana yang ingin Anda gunakan untuk otentikasi.
Ketika mekanisme yang digunakan oleh aplikasi adalah
sudo
(untuk tugas-tugas admin yang dilakukan melalui GUI ini menjadi kurang sering), Anda tidak memiliki sarana langsung dan sederhana untuk memilih pengguna untuk otentikasi.sumber
Jelas,
sudo
akan menjadi pilihan pertama bagi saya dalam kasus seperti itu. The muncul titik utama untuk menjadi yang paling (aktual) admin tidak benar-benar menggunakan/etc/sudoers
untuk sepenuhnya kemungkinan (User_Alias
,Runas_Alias
,Host_Alias
,Cmnd_Alias
).Sebagian besar admin akhirnya hanya menggunakan beberapa aturan yang ada dan menambahkan pengguna, atau lebih buruk, hanya menambahkan pengguna ke
sudo
grup yang biasanya ada aturan pada pengaturan Ubuntu (%sudo
...). Ini, tentu saja, memberikan masing-masing pengguna pemerintahan bebas dan kekuatan penuh dari akun pengguna super.Diberikan komentar Anda:
Saya rasa Anda juga tidak menggunakannya sejauh mungkin.
Dalam skenario seperti skenario Anda, saya benar-benar akan menulis beberapa tindakan yang membatasi Bob. Sebenarnya ini adalah apa yang saya lakukan pada server yang saya pelihara, untuk memungkinkan dua pengguna tertentu untuk me-reboot tamu KVM tertentu pada sebuah host. Script akan berisi hashbang dengan jalur absolut ke penerjemah (misalnya
#!/bin/dash
alih-alih#!/usr/bin/env bash
) dan mungkin dijalankan dengan shell yang digunakan di tempat lain untuk tugas-tugas istimewa (/bin/dash
atau/bin/sh
). Itu hanya tindakan pencegahan. Selain itu, saya akan memastikan untuk meng-hardcode semua path absolut ke binari dan menggunakan sesedikit mungkin dari mereka. Misalnya ketika menggunakanbash
/dash
saya lebih sukabuiltin
s lebihcommand
dari (lihatman bash
). Anda bisa menjadikan ini dapat dipertahankan dengan menetapkan variabel sebagai jalur absolut dan merujuk ke program berdasarkan pada variabel itu ($VIRSH
bukannya/usr/bin/virsh
). Jika Anda bisa, periksa kode skrip eksternal apa pun sebelum memanggilnya. Terutama jika Anda perlu memanggil mereka dalam konteks istimewa. Dalam kasus saya, saya juga membatasi pengguna ke direktori root tertentu dan subsistem SSH tertentu karena mereka hanya terhubung ke mesin melaluisshd
dan otentikasi kunci publik. Jelas Anda tidak membutuhkannya.Pastikan
chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>
untuk mencegah siapa pun kecualiroot
bermain-main dengannya. Juga berhati-hati dengansetuid
dansetgid
bit diaktifkan pada binari sasaran (find
dapat digunakan untuk melihat mereka). Mari kita asumsikan saat skrip Anda berada/usr/sbin/priv-action
.Sekarang edit
/etc/sudoers
.noexec
dapat digunakan untuk mencegah binari lain selain dari yang diizinkan secara eksplisit juga. Sebenarnya ada banyak pengaturan tambahan, bukan hanya yang saya jelaskan di sini. Jadi pastikan untuk berkonsultasiman sudoers
.Sekarang saya lebih suka memberi nama pengguna (
User_Alias
) dalamsudoers
file saya , tetapi Anda bisa menggunakanGroup_Alias
(man sudoers
) atau grup sistem aktual (misalnya%sudo
):dan kemudian tambahkan perintah alias untuk memungkinkan mengeksekusi skrip tertentu:
Terakhir namun tak kalah penting, muncul garis ajaib untuk mengizinkan
bob
(atau lebih tepatnya pengguna yang tercantum di bawahLIMITED_ADMINS
) untuk mengeksekusi perintah istimewa melalui skrip:Berbeda dengan definisi alias sebelumnya, baris itu membutuhkan penjelasan. Jadi pertama-tama mari kita gali bagian-bagian pada garis rata-rata "Spesifikasi Pengguna". Di sini
man sudoers
membantu:Baris contoh (ditemukan pada sebagian besar pengaturan Ubuntu):
Ini mengatakan bahwa seorang pengguna bernama
root
(gunakan#0
untuk mengikatnya ke UID0
) dapat, pada semua host, berjalan di bawah konteks apa pun pengguna tetapi akan diminta untuk kata sandinya (dengan asumsi perilaku default). MenambahkanNOPASSWD
tag sebelum yang terakhirALL
juga akan memungkinkanroot
untuk melakukan hal yang sama tanpa diminta kata sandi (seperti:)root ALL=(ALL) NOPASSWD:ALL
.ALL
adalah alias wildcard intrinsik untuk berbagai jenis alias.Tapi kembali ke Bob:
akan mengizinkan
bob
dan anggota terdaftar lainnyaUser_Alias LIMITED_ADMINS
untuk menjalankan (pada semua host, itulah gunanyaALL
) sebagai penggunaroot
(grup tersirat, tetapi dapat diberikan, lihatman sudoers
) perintah yang diberikan dalamCmnd_Alias PRIV_ACTION
. Semakin membaik. Masih dengan asumsi Anda menulis skrip ini, Anda dapat mengizinkan berbagai parameter, sehingga menghindari untuk menulis banyak skrip./etc/sudoers
dengan senang hati mengambil wildcard seperti shell untuk membatasi kemungkinan argumen diizinkan untuk disahkan.Saya secara konsisten menemukan bahwa admin tidak menggunakan
sudoers
cara yang seharusnya digunakan, itulah sebabnya saya menghargai masing-masing "Retas" dari dua buku "Linux Server Hacks" dan "Linux Server Hacks Volume Two", yang membuat saya mulai dengan penggunaan yang lebih canggih dari fasilitas hebat ini.Anda dapat menemukan semua jenis berbelit-belit - yang mungkin tidak persis membantu aspek keamanan - solusi untuk kasus khusus Anda, tetapi begitu Anda berbicara kosakata dasar
/etc/sudoers
Anda dapat melakukan prestasi yang cukup ajaib :)NB: perlu diingat bahwa Anda juga dapat membuat file baru di bawahnya
/etc/sudoers.d/
jika Anda merasa sangat ingin. Ini mengasumsikan Anda/etc/sudoers
mengandung baris:sumber
Hanya ada satu pengguna super di Unix / Linux, namanya root, tetapi sudoers adalah pengguna yang bisa menjadi root. Anda harus menggunakan grup:
dan kemudian menetapkan pengguna ke grup itu:
kemudian tambahkan grup admin ke file konfigurasi sudoers seperti jika grup itu pengguna.
Memperbarui
Atau Anda dapat menambahkan pengguna apa pun ke grup admin:
sumber
adduser <user>
,addgroup <group>
danadduser <user> <group>
adalah cara yang lebih disukai pada Debian / Ubuntu.