Ketika Ubuntu meminta kata sandi pengguna admin, bagaimana cara memutuskan pengguna administratif yang diminta?


11

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/sudoerskarena 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?


Alternatifnya adalah mengizinkan perintah terkait virtualisasi secara otomatis menggunakan hak admin. Saya yakin saya membaca pertanyaan tentang itu, tetapi saya lupa.
Oxwivi

Googling cepat memberi tahu saya bahwa Anda melakukannya dari sudoersfile yang sama , Anda dapat memeriksa halaman manualnya untuk info lebih lanjut.
Oxwivi

Saya mempertimbangkan hal itu ketika saya mengedit sudoers: ini bukan pilihan pertama karena masalah keamanan. Juga lihat jawaban enzotib - bagian dari masalahnya adalah kebingungan antara sudodan PolicyKit.
Brighid McDonnell

Jawaban:


9

Pertama-tama biarkan untuk menunjukkan bahwa tindakan istimewa diizinkan untuk pengguna non-root melalui dua mekanisme berbeda.

  1. sudo

  2. PolicyKit

Yang pertama digunakan ketika Anda secara eksplisit menjalankan perintah dengan sudoatau item menu yang perintahnya dibungkus gksu(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 :)

masukkan deskripsi gambar di sini

Anda dapat mengidentifikasi PolicyKit dari segitiga hitam kecil dan Rincian label . Seperti yang dapat Anda lihat, jika lebih dari satu pengguna dalam admingrup, Anda dapat memilih dari daftar pengguna mana yang akan digunakan untuk otentikasi.

Mengingat semua ini, keduanya sudodan 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.


1
Saya merasa seperti saya memiliki pemahaman yang jauh lebih baik tentang situasi sekarang. Terima kasih.
Brighid McDonnell

6

Jelas, sudoakan menjadi pilihan pertama bagi saya dalam kasus seperti itu. The muncul titik utama untuk menjadi yang paling (aktual) admin tidak benar-benar menggunakan /etc/sudoersuntuk 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 sudogrup 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:

jadi saya menambahkannya ke /etc/sudoers

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/dashalih-alih #!/usr/bin/env bash) dan mungkin dijalankan dengan shell yang digunakan di tempat lain untuk tugas-tugas istimewa ( /bin/dashatau /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 menggunakan bash/ dashsaya lebih suka builtins lebih commanddari (lihat man bash). Anda bisa menjadikan ini dapat dipertahankan dengan menetapkan variabel sebagai jalur absolut dan merujuk ke program berdasarkan pada variabel itu ($VIRSHbukannya /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 melalui sshddan otentikasi kunci publik. Jelas Anda tidak membutuhkannya.

Pastikan chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>untuk mencegah siapa pun kecuali rootbermain-main dengannya. Juga berhati-hati dengan setuiddan setgidbit diaktifkan pada binari sasaran ( finddapat digunakan untuk melihat mereka). Mari kita asumsikan saat skrip Anda berada /usr/sbin/priv-action.

Sekarang edit /etc/sudoers. noexecdapat 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 berkonsultasi man sudoers.

Sekarang saya lebih suka memberi nama pengguna ( User_Alias) dalam sudoersfile saya , tetapi Anda bisa menggunakan Group_Alias( man sudoers) atau grup sistem aktual (misalnya %sudo):

# The list is comma-separated: bob,alice,...
User_Alias      LIMITED_ADMINS=bob

dan kemudian tambahkan perintah alias untuk memungkinkan mengeksekusi skrip tertentu:

# The list is comma-separated: /usr/sbin/priv-action,/bin/bash,...
Cmnd_Alias      PRIV_ACTION=/usr/sbin/priv-action

Terakhir namun tak kalah penting, muncul garis ajaib untuk mengizinkan bob(atau lebih tepatnya pengguna yang tercantum di bawah LIMITED_ADMINS) untuk mengeksekusi perintah istimewa melalui skrip:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

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 sudoersmembantu:

Struktur dasar spesifikasi pengguna adalah who where = (as_whom) what.

Baris contoh (ditemukan pada sebagian besar pengaturan Ubuntu):

root    ALL=(ALL) ALL

Ini mengatakan bahwa seorang pengguna bernama root (gunakan #0untuk mengikatnya ke UID 0) dapat, pada semua host, berjalan di bawah konteks apa pun pengguna tetapi akan diminta untuk kata sandinya (dengan asumsi perilaku default). Menambahkan NOPASSWDtag sebelum yang terakhir ALLjuga akan memungkinkan rootuntuk melakukan hal yang sama tanpa diminta kata sandi (seperti:) root ALL=(ALL) NOPASSWD:ALL. ALLadalah alias wildcard intrinsik untuk berbagai jenis alias.

Tapi kembali ke Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

akan mengizinkan bobdan anggota terdaftar lainnya User_Alias LIMITED_ADMINSuntuk menjalankan (pada semua host, itulah gunanya ALL) sebagai pengguna root(grup tersirat, tetapi dapat diberikan, lihat man sudoers) perintah yang diberikan dalam Cmnd_Alias PRIV_ACTION. Semakin membaik. Masih dengan asumsi Anda menulis skrip ini, Anda dapat mengizinkan berbagai parameter, sehingga menghindari untuk menulis banyak skrip. /etc/sudoersdengan senang hati mengambil wildcard seperti shell untuk membatasi kemungkinan argumen diizinkan untuk disahkan.

Saya secara konsisten menemukan bahwa admin tidak menggunakan sudoerscara 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/sudoersAnda 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/sudoersmengandung baris:

#includedir /etc/sudoers.d

-1

Hanya ada satu pengguna super di Unix / Linux, namanya root, tetapi sudoers adalah pengguna yang bisa menjadi root. Anda harus menggunakan grup:

newgrp admins

dan kemudian menetapkan pengguna ke grup itu:

chgrp alice admins

kemudian tambahkan grup admin ke file konfigurasi sudoers seperti jika grup itu pengguna.

Memperbarui

Atau Anda dapat menambahkan pengguna apa pun ke grup admin:

chgrp alice admin

Maaf saya menekan tombol tab dan mengirimnya tanpa menyelesaikannya.
Francisco Valdez

Komentar Zorched berdasarkan jawaban yang tidak lengkap. Mencoba jawaban saat ini. Dengan asumsi bahwa eksposisi tambahan adalah untuk pembaca masa depan mungkin kurang mengenal tugas sysadmin.
Brighid McDonnell

Tentu saja saya tidak bermaksud menjadi sombong, ada situs stackexchange tentang sysadmin
Francisco Valdez

Saya tahu ServerFault ada. Saya bertanya di sini karena ini adalah perilaku spesifik Ubuntu.
Brighid McDonnell

AFAIK: adduser <user>, addgroup <group>dan adduser <user> <group>adalah cara yang lebih disukai pada Debian / Ubuntu.
0xC0000022L
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.