C'è qualcosa tra un normale account utente e root?

Question

Sto sviluppando un'applicazione che gestisce le interfacce di rete per conto dell'utente e chiama diversi programmi esterni (come ifconfig) che richiedono root per apportare modifiche. (In particolare, cambiando l'indirizzo IP di un'interfaccia locale, ecc.) Durante lo sviluppo, ho eseguito l'IDE come root (ugh) e il debugger come root (double-ugh). C'è un buon modo per l'utente finale di eseguirli con un account non root? Non mi piace molto la dimensione della superficie di attacco presentata da GTK, wxPython, Python e la mia applicazione quando viene eseguita come root.

Ho esaminato le funzionalità, ma sembrano semi-cotte e non sono sicuro che sarei in grado di usarle in Python, specialmente se sono basate su thread. L'unica opzione che non ho esplorato è un demone che ha impostato il bit setuid e fa tutte le cose di tipo root per conto dell'interfaccia utente. Sono titubante nel presentare questa complessità così presto nel progetto, in quanto l'esecuzione come root non è un rompicapo per gli utenti.

Answer 1

La tua idea sul demone ha molto merito, nonostante la complessità che introduce. Finché le azioni non richiedono alcune interazioni dell'interfaccia utente come root , un demone ti consente di controllare quali operazioni sono consentite e non consentite.

Tuttavia, puoi utilizzare SUDO per creare un compromesso controllato tra ROOT e gli utenti normali ... concedi semplicemente l'accesso SUDO agli utenti in questione per gli strumenti specifici di cui hanno bisogno. Ciò riduce la superficie di attacco consentendo solo "consentito". root viene avviato.

Answer 2

Quello che vuoi è un " Gruppo "

Si crea un gruppo, si specifica che l'account che desidera eseguire l'azione appartiene al gruppo, quindi si specifica che la risorsa a cui si desidera accedere è un membro di quel gruppo.

A volte la gestione dei gruppi può essere in qualche modo irritante, ma dovrebbe permetterti di fare tutto quello che vuoi, ed è l'utente autorizzato, non il tuo programma.

(Se si desidera che il proprio programma sia autorizzato, è possibile creare un utente specifico per eseguirlo come tale e fornire a tale utente l'appartenenza al gruppo appropriata, quindi fare clic su quel gruppo all'interno del programma per eseguire l'operazione senza dare all'utente in esecuzione la possibilità. )

Answer 3

È possibile creare e distribuire una politica selinux per la propria applicazione. Selinux consente il tipo di accesso a grana fine di cui hai bisogno. Se non puoi o non vuoi usare selinux, allora il demone è la strada da percorrere.

Answer 4

Non vorrei eseguire l'applicazione a tempo pieno come root, ma potresti voler esplorare rendendo root setuid della tua applicazione, o setuid su qualche id che può diventare root usando qualcosa come sudo per applicazioni particolari. Potresti essere in grado di impostare un account che non può accedere, utilizzare setuid per modificare l'ID del tuo programma (temporaneamente quando necessario) e avere impostato sudo per non richiedere la password, ma consentire sempre l'accesso a tale account per attività specifiche.

In questo modo il tuo programma non ha privilegi speciali quando funziona normalmente, eleva i suoi privilegi solo quando necessario ed è limitato da sudo all'esecuzione solo di determinati programmi.

È passato un po 'di tempo da quando ho fatto molto sviluppo su Unix, quindi non sono davvero sicuro se sia possibile impostare sudo per non richiedere una password (o anche se c'è un'API per esso), ma come fallback potresti abilitare setuid a root solo quando necessario.

[EDIT] Sembra che sudo abbia una modalità NOPASSWD, quindi penso che dovrebbe funziona poiché stai eseguendo i programmi come comandi esterni.

Answer 5

Il modo tradizionale sarebbe quello di creare e usare un aiuto setuid per fare tutto ciò di cui hai bisogno. Nota, tuttavia, scrivere correttamente un aiutante setuid è complicato (ci sono diversi vettori di attacco che devi proteggere).

Il modo moderno sarebbe usare un demone (in esecuzione come root, avviato all'avvio) che ascolta le richieste dal resto dell'applicazione. In questo modo, la tua superficie di attacco è per lo più limitata a qualsiasi IPC tu scelga (suggerirei d-bus, che sembra essere il modo moderno).

Infine, se gestisci le interfacce di rete, ciò che fai è molto simile a quello che fa il gestore di rete su una distribuzione moderna. Sarebbe una buona idea provare a integrare in qualche modo ciò che stai facendo con il gestore della rete (quindi non entrerà in conflitto con le tue manipolazioni), o almeno a vedere come funziona.

Answer 6

Non esiste un singolo utente che si trovi a metà strada tra un " normale " utente e root. Hai root e quindi hai utenti; gli utenti possono avere diversi livelli di capacità. Se vuoi qualcosa di più potente di un "normale" utente ma non potente come root, devi solo creare un nuovo utente con le funzionalità che desideri, ma non assegnargli i privilegi che non desideri che abbiano.

Answer 7

Non ho abbastanza familiarità con Python per dirti quali sarebbero i comandi necessari in quella lingua, ma dovresti essere in grado di farlo attraverso il fork e l'uso di una pipe per comunicare tra i processi genitore e figlio. Qualcosa del genere:

• Esegui il programma come root tramite sudo o suid
• All'avvio, il programma esegue immediatamente il fork e stabilisce una pipe per la comunicazione tra i processi padre e figlio
• Il processo figlio mantiene la potenza di root, ma resta lì in attesa di input dalla pipe
• Il processo parent rilascia root (cambia il suo uid in quello dell'utente che lo esegue), quindi visualizza la GUI, interagisce con l'utente e gestisce tutte le operazioni disponibili per un utente non privilegiato
• Quando si deve eseguire un'operazione che richiede i privilegi di root, il processo parent (non root) invia un comando down the pipe al processo child (root) che lo esegue e facoltativamente riporta al genitore

È probabile che questo sia un po 'più facile da scrivere rispetto a un demone indipendente, oltre che più conveniente da eseguire (poiché non è necessario preoccuparsi se il demone è in esecuzione o meno), consentendo al contempo la GUI e altre cose che non necessitano di poteri di root per essere eseguite come non-root.