Quando Ubuntu chiede la password di un utente amministratore, come decide quale utente amministrativo chiedere?

Sto installando una macchina Ubuntu (10.10) che verrà utilizzata da diverse persone. È una macchina condivisa in un piccolo ufficio. I suoi ruoli principali sono l'hosting di macchine virtuali con VirtualBox e la fornitura di file con Samba.

Per Samba, è necessario configurare diversi account utente in modo che diverse persone possano connettersi alle condivisioni Samba dalle proprie workstation. Tuttavia, esiste anche un account dedicato alla sola esecuzione di macchine virtuali che verranno utilizzate da più persone. A volte le persone cercano di fare cose con questo account che richiedono privilegi elevati - questo fa apparire la finestra di dialogo "inserisci la password di un utente amministrativo" di Gnome. Tuttavia, questa finestra di dialogo richiede la mia password: quando ho impostato la macchina, il mio è stato il primo account creato, quindi sembra presumere che io sia l'unico utente a cui sono stati concessi i poteri sudo.

Voglio designare un altro utente come "amministratore di prima istanza", per così dire, e non può essere l'utente dell'account condiviso, perché tutti devono conoscere la password di quell'account, quindi voglio che i suoi privilegi siano strettamente limitati. Non può essere il mio account, dal momento che non sto dicendo a nessuno la mia password, e non sarò presente sul sito abbastanza spesso per inserirla da solo. C'è, però, qualcuno che può farlo di persona, quindi l'ho aggiunto a /etc/sudoers. Come posso dire a Ubuntu che quando deve elevare i privilegi per qualcosa, dovrebbe prima chiedere il loro account?

Riassumere:

• Conti sulla macchina: Alice, Bob, Carol, Dave, Eliza.
• Quando fu installato Ubuntu, Alice fu il primo utente, aggiunto durante il processo di installazione.
• "Dave" è in realtà un account utilizzato da molte persone, a cui non è possibile accedere /etc/sudoersperché la sua password è di dominio pubblico.
• Bob è stato impostato per essere un account "amministrativo" in Gnome ed è opportunamente inserito /etc/sudoers- Bob è il capo in questo ufficio.
• Quando vengono tentate azioni che richiedono privilegi elevati durante l'accesso come Bob, Carol, Eliza o Dave, il sistema dovrebbe richiedere le credenziali di Bob.
• Quando vengono tentate azioni che richiedono privilegi elevati durante l'accesso come Alice, il sistema dovrebbe richiedere le credenziali di Alice (sebbene Alice sia una specie di amministratore di sistema buckaroo e abbia l'abitudine di utilizzare su -per eseguire attività amministrative estese).

Quali modifiche alla configurazione devo apportare per ottenere lo stato desiderato qui?

Innanzitutto, lasciamo rilevare che le azioni privilegiate sono consentite per un utente non root attraverso due diversi meccanismi.

1. sudo

2. PolicyKit

Il primo viene utilizzato quando si esegue esplicitamente un comando con sudoo una voce di menu il cui comando è racchiuso gksu(come Synaptic Package Manager ).
In questo caso la password richiesta è quella dell'utente che invoca, generalmente l'utente che ha effettuato l'accesso.

Il secondo viene utilizzato quando un'applicazione compatibile con PolicyKit tenta di eseguire un'azione privilegiata. In tal caso, l'applicazione richiede all'autorità locale PolicyKit (tramite D-Bus) se è possibile eseguire l'azione. L'autorità locale quindi, tramite un agente di autenticazione, chiede all'utente attivo di dimostrare la sua identità. Le finestre di dialogo sono le seguenti (sfortunatamente con testo in italiano :)

È possibile identificare PolicyKit dal piccolo triangolo nero e dall'etichetta Dettagli . Come puoi vedere, se più di un utente è nel admingruppo, puoi scegliere dall'elenco quale utente utilizzare per l'autenticazione.

Alla luce di tutto ciò, entrambi sudoe PolicyKit sono molto più complicati, rispetto alle configurazioni che è possibile ottenere: è possibile configurare azioni che possono essere eseguite senza password, eseguite solo da un determinato utente o gruppo, ecc.

Venendo alla tua domanda, quando il meccanismo utilizzato dall'applicazione è PolicyKit, indipendentemente dall'utente attualmente connesso, la password richiesta sarebbe quella di Bob o Alice (l'unico utente di due amministratori, se ho capito bene), e puoi cambiare dall'elenco quale utente si desidera utilizzare per l'autenticazione.

Quando il meccanismo utilizzato dall'applicazione è sudo(per le attività di amministrazione eseguite tramite la GUI questo sta diventando meno frequente), non hai mezzi immediati e semplici per scegliere l'utente per l'autenticazione.

Chiaramente, sudosarebbe la prima scelta per me in questo caso. I appare importante punto di essere che la maggior parte (effettivi) amministratori non effettivamente utilizzare /etc/sudoersal massimo misura possibile ( User_Alias, Runas_Alias, Host_Alias, Cmnd_Alias).

La maggior parte degli amministratori finisce per usare solo alcune delle regole esistenti e aggiungere utenti, o peggio, semplicemente aggiungere utenti al sudogruppo per il quale di solito esiste una regola sui setup di Ubuntu ( %sudo...). Questo, ovviamente, offre ai rispettivi utenti il ​​regno gratuito e la piena potenza dell'account superutente.

Dato il tuo commento:

così li ho aggiunti a /etc/sudoers

Credo che anche tu non lo usi nella misura del possibile.

In uno scenario come il tuo, scriverei letteralmente le poche azioni a cui Bob deve essere limitato. In effetti questo è ciò che ho fatto su un server che mantengo, per consentire a due utenti particolari di riavviare un particolare ospite KVM su un host. Gli script conterrebbero un hashbang con percorso assoluto all'interprete (ad esempio #!/bin/dashinvece di #!/usr/bin/env bash) e probabilmente eseguito con una shell che viene utilizzata altrove per attività privilegiate ( /bin/dasho /bin/sh). Queste sono solo precauzioni. A parte questo, mi assicurerei di codificare tutti i percorsi assoluti verso i binari e utilizzarne il minor numero possibile. Ad esempio quando si utilizza bash/ dashI preferirei builtins rispetto a commands (vedi man bash). Puoi renderlo mantenibile assegnando una variabile al percorso assoluto e facendo riferimento al programma basato su quella variabile ($VIRSHinvece di /usr/bin/virsh). Se puoi, controlla il codice di tutti gli script esterni prima di chiamarli. Soprattutto se è necessario chiamarli in un contesto privilegiato. Nel mio caso, limito anche gli utenti a una directory root particolare e a un sottosistema SSH particolare poiché si connettono solo alla macchina tramite sshde autenticazione con chiave pubblica. Ovviamente non ne hai bisogno.

Assicurati chown root: <the-script>; chmod u=rw,a=,a+rx <the-script>di impedire a chiunque, se non rootproprio, di armeggiare con esso. Anche stare attenti con setuide setgidbit abilitati binari di destinazione ( findpuò essere utilizzato per individuarli). Supponiamo per il momento in cui risiede il tuo script /usr/sbin/priv-action.

Ora modifica il tuo /etc/sudoers. noexecpuò essere utilizzato per prevenire altri file binari oltre a quelli esplicitamente consentiti. In realtà ci sono molte altre impostazioni, non solo quelle che sto descrivendo qui. Quindi assicurati di consultare man sudoers.

Ora preferisco nominare gli utenti ( User_Alias) nel mio sudoersfile, ma potresti anche usare un Group_Alias( man sudoers) o un gruppo di sistema reale (ad es. %sudo):

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

e quindi aggiungere un alias di comando per consentire l'esecuzione di quel particolare script:

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

Ultimo ma non meno importante, arriva la linea magica per consentire bob(o meglio gli utenti elencati sotto LIMITED_ADMINS) di eseguire i comandi privilegiati tramite lo script:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

A differenza delle precedenti definizioni di alias, quella linea richiede una spiegazione. Quindi, prima scaviamo nelle parti su una media di riga "User Specification". Qui man sudoersaiuta:

La struttura di base di una specifica dell'utente è who where = (as_whom) what.

Riga di esempio (presente nella maggior parte delle configurazioni di Ubuntu):

root    ALL=(ALL) ALL

Ciò significa che un utente di nome root (utilizzato #0per collegarlo all'UID 0) può, su tutti gli host, eseguire qualsiasi contesto utente, ma verrà richiesta la sua password (presupponendo un comportamento predefinito). L'aggiunta del NOPASSWDtag prima dell'ultimo ALLconsentirebbe quindi rootdi fare lo stesso senza che venga richiesta una password (in questo modo:) root ALL=(ALL) NOPASSWD:ALL. ALLè un alias jolly intrinseco per i vari tipi di alias.

Ma torniamo a Bob:

LIMITED_ADMINS  ALL=(root) PRIV_ACTION

consentirebbe bobe altri membri elencati di User_Alias LIMITED_ADMINSeseguire (su tutti gli host, ecco a cosa ALLserve) come utente root(gruppo implicito, ma potrebbe essere dato, vedi man sudoers) i comandi dati in Cmnd_Alias PRIV_ACTION. Va meglio. Partendo dal presupposto che tu scriva questo script, potresti consentire vari parametri, evitando così di scrivere più script. /etc/sudoersaccetta volentieri i caratteri jolly simili a shell per limitare le possibilità di argomenti che possono essere passati.

Ho costantemente scoperto che gli amministratori non usano sudoersil modo in cui dovrebbe essere usato, motivo per cui ho apprezzato il rispettivo "Hack" dai due libri "Linux Server Hacks" e "Linux Server Hacks Volume Two", che mi ha fatto iniziare con un uso più sofisticato di questa grande struttura.

Puoi trovare tutti i tipi di soluzioni contorte - che potrebbero non aiutare esattamente l'aspetto della sicurezza - per il tuo caso particolare, ma una volta che parli il tuo vocabolario di base /etc/sudoerspuoi eseguire imprese piuttosto magiche :)

NB: tieni presente che puoi anche creare un nuovo file sotto /etc/sudoers.d/se ti senti così incline. Questo presuppone che tu /etc/sudoerscontenga la riga:

#includedir /etc/sudoers.d

Esiste un solo superutente in Unix / Linux, il suo nome è root, ma i sudoer sono utenti che possono diventare root. Dovresti usare gruppi:

newgrp admins

e quindi assegnare gli utenti a quel gruppo:

chgrp alice admins

quindi aggiungi il gruppo admin al file di configurazione sudoers come se il gruppo fosse un utente.

Aggiornare

Oppure puoi aggiungere qualsiasi utente al gruppo admin:

chgrp alice admin