Consentire agli utenti non amministratori di installare pacchetti tramite apt o rpm?

13

È possibile consentire agli utenti non root di installare pacchetti a livello di sistema usando apt o rpm?

Il posto in cui lavoro attualmente ha una configurazione obsoleta sulle scatole di Linux e gli amministratori sono stanchi di dover fare tutte le installazioni per gli utenti su richiesta, quindi stanno pensando di dare diritti sudo completi a tutti gli utenti. Ciò presenta evidenti svantaggi di sicurezza. Quindi mi chiedo se c'è un modo per consentire agli utenti normali di installare software e di aggiornarlo e rimuoverlo?

— naught101
fonte

4

Se dai i privilegi per installare i pacchetti, hai essenzialmente dato i diritti di amministratore completi, poiché un utente potrebbe semplicemente installare un pacchetto con una shell setuid-root.

— Camh,

@camh hrm .. potresti avere un repository controllato e non consentire agli utenti di aggiungere nuovi repository, no? O apt ti permette di installare pacchetti da file .deb? Mi rendo conto che un repository veterinario sarebbe probabilmente più lavoro a lungo termine, questa è più una domanda concettuale :)

— nought101

1

apt-secure(8)dice: "apt-get attualmente avviserà solo di archivi non firmati, le versioni future potrebbero forzare la verifica di tutte le fonti prima di scaricare i pacchetti da loro". A seconda di quanto sia sofisticato un attacco, potrebbe essere possibile dirottare la connessione alla fonte del repository e iniettare un pacchetto non attendibile. Tuttavia, leggi quella pagina man per maggiori dettagli. Potresti avere una soluzione abbastanza sicura per il tuo modello di thread.

— Camh,

Correlati: Sistema di gestione dei pacchetti locale dell'utente

— Piotr Dobrogost,

1

Correlati: Gestori di pacchetti non root

— Piotr Dobrogost,

21

È possibile specificare i comandi consentiti con sudo, non è necessario consentire l'accesso illimitato, ad es

username ALL = NOPASSWD : /usr/bin/apt-get , /usr/bin/aptitude

Ciò consentirebbe l'esecuzione del nome utente sudo apt-gete sudo aptitudesenza password, ma non consentirebbe altri comandi.

È inoltre possibile utilizzare il pacchetto pacchetto combinato con PolicyKit per un livello di controllo più preciso rispetto a sudo.

Consentire agli utenti di installare / rimuovere pacchetti può essere un rischio. Possono facilmente rendere un sistema non funzionale semplicemente disinstallando il software necessario come libc6, dpkg, rpm ecc. L'installazione di software arbitrario dagli archivi definiti può consentire agli aggressori di installare software obsoleto o sfruttabile e ottenere l'accesso root. La domanda principale secondo me è quanto ti fidi dei tuoi dipendenti?

Ovviamente il tuo team di amministratori potrebbe anche iniziare a utilizzare un sistema di gestione della configurazione come pupazzo, cuoco o guardare spacewalk per gestire il tuo sistema. Ciò consentirebbe loro di configurare e gestire il sistema da un sistema centrale.

— Ulrich Dangel
fonte

L'ho lasciato fuori dalla mia domanda, ma hai qualche commento sulla riduzione di sicurezza implicita permettendo questo? Voglio dire, non è possibile modificare i repository di pacchetti, quindi probabilmente non si otterrà l'accesso completo sudo, ma è possibile scrivere su qualsiasi file utilizzando aptitude (opzioni> preferenze> "File per accedere alle azioni"), che potrebbe causare alcuni gravi danni. Sono meno sicuro di PolicyKit ...

— nought101

1

@ naught101 ok ho aggiunto alcuni commenti sulla sicurezza. JFTR come policykit non fornirà l'accesso come root sarebbe meno problematico rispetto all'utilizzo di sudo

— Ulrich Dangel,

Esistono modi per eseguire una shell da dpkg o rpm. Ad esempio: dpkg verrà richiesto in caso di modifica del file di configurazione che si scontra, con una delle opzioni che avvia una shell per esaminare la situazione . Questo avvierà una shell come root se eseguito tramite sudo. Allo stesso modo se è possibile eseguire un editor dallo strumento, poiché la maggior parte degli editor consente di eseguire comandi di shell arbitrari al loro interno (ad esempio! Command in vi).

— David Gardner,

@ naught101 Verificherei l'escalation dei privilegi tramite un RPM che contiene una shell SUID come descrive questo blog: nosedookie.blogspot.com/2011/07/… In uno scenario di iniezione shell, tuttavia, in cui l'account sudoer è compromesso, si potrebbe mitigare escalazione di privilegi tramite sudo richiedendo l'inserimento di una password , anziché NOPASSWD.

— Matt,

7

aptdcon

Dalle pagine man:

aptdcon: consente di eseguire attività di gestione dei pacchetti, ad es. installazione o rimozione di software, tramite aptdaemon. Non è necessario essere root per eseguire questo programma.

— pl1nk
fonte

1

Anche se non hai bisogno dei privilegi di root / sudo per eseguire aptdcon, avvia immediatamente una finestra di autenticazione per utenti non privilegiati - ho appena testato su Ubuntu. Se non sei un utente privilegiato / autorizzato, questo non aggiunge / rimuove i pacchetti.

— salvia il

1

Non funziona sulle operazioni

ERROR: You are not allowed to perform this action. ('system-bus-name', {'name':  ':1.716'}): org.debian.apt.install-or-remove-packages

— JacopKane,

4

username ALL = NOPASSWD : /usr/bin/yum, /bin/rpm

— fromnaboo
fonte

1

Ho anche cercato qualcosa del genere, ma non è apparso nulla, quindi ho codificato questa semplice soluzione "softwarechannels":

https://github.com/alfem/softwarechannels

È un sistema molto semplice per consentire agli utenti comuni (senza amministratore) di installare pacchetti da cataloghi limitati.

Definisci semplicemente "canali" (gruppi di pacchetti) in un semplice file di testo e dai ai tuoi utenti le autorizzazioni per avviare i softwarechannel.

Vedranno solo i pacchetti nei canali corrispondenti ai loro gruppi unix.

— Alfonso EM
fonte