Stiamo riscontrando un piccolo problema su un server. Vogliamo che alcuni utenti siano in grado di fare ad es. sudoDiventare root, ma con la limitazione che l'utente non può cambiare la password di root. Cioè, una garanzia che possiamo ancora accedere a quel server e diventare root indipendentemente da ciò che faranno gli altri utenti.

È possibile?

Vogliamo che alcuni utenti siano in grado di fare ad esempio sudoe diventare root,

Bene, questo è il problema che sudo è progettato per risolvere, quindi quella parte è abbastanza semplice.

ma con la limitazione che l'utente non può cambiare la password di root.

Come SHW ha sottolineato in un commento, è possibile configurare sudo in modo che determinate azioni possano essere eseguite come root da determinati utenti. Cioè, si può permettere di fare user1 sudo services apache2 restart, user2 permettere di fare sudo rebootma nient'altro, pur consentendo il sistema amministratore assunto-as- user3a fare sudo -i. Ci sono howtos disponibili su come impostare sudo in questo modo, oppure puoi cercare (o chiedere) qui. Questo è un problema risolvibile.

Tuttavia, un utente a cui è stata concessa la capacità sudo -io sudoall'interno di una shell ( sudo bashad esempio) può fare qualsiasi cosa. Questo perché al momento in cui sudo avvia la shell, sudo stesso non è più visibile. Fornisce il contesto di sicurezza di un altro utente (molto spesso root), ma non ha voce in capitolo su ciò che fa l'applicazione eseguita. Se a sua volta l'applicazione viene avviata, passwd rootsudo non può farci nulla. Nota che questo può essere fatto anche attraverso altre applicazioni; per esempio, molti degli editor più avanzati forniscono funzionalità per eseguire un comando attraverso la shell, una shell che verrà eseguita con l'uid efficace di quel processo di editor (ovvero root).

Cioè, una garanzia che possiamo ancora accedere a quel server e diventare root indipendentemente da ciò che faranno gli altri utenti.

Scusate; se intendi davvero "assicurati che saremo in grado di accedere e utilizzare il sistema indipendentemente da ciò che qualcuno con accesso root vi farà", ciò (a tutti gli effetti) non può essere fatto. Un veloce "sudo rm / etc / passwd" o "sudo chmod -x / bin / bash" (o qualunque cosa usi la radice della shell) e tu sei praticamente tolto comunque. "Praticamente hosed" significa "dovrai ripristinare dal backup e sperare che non abbiano fatto nulla di peggio di uno scivolo di dita". Puoi prendere alcune misure per ridurre il rischio di un incidente accidentale che porta a un sistema inutilizzabile, ma non puoi impedire alla malizia di causare problemi molto gravi fino al punto di necessità di ricostruire il sistema da zero o per lo meno da noto buoni backup.

Dando a un utente l'accesso root illimitato su un sistema, ti fidi di quell'utente (incluso qualsiasi software che potrebbe scegliere di eseguire, anche qualcosa di banale come il suo) di non avere intenzioni malevole e di non sbagliare per caso. Questa è la natura dell'accesso root.

L' accesso limitato alla radice, ad esempio sudo, è un po 'meglio, ma bisogna comunque fare attenzione a non aprire alcun vettore di attacco. E con l'accesso root, ci sono molti possibili vettori di attacco per attacchi di escalation di privilegi.

Se non puoi fidarti di loro con il livello di accesso che comporta essere root, avrai bisogno di una configurazione sudo molto ristretta, o semplicemente di non concedere all'utente in questione l'accesso root in alcun modo, sudo o altro.

Questo è praticamente impossibile. Prima di tutto, se concedi loro il potere di diventare root , non c'è niente che puoi fare per impedire loro di fare qualcosa. Nel tuo caso d'uso, sudodovrebbe essere usato per concedere ai tuoi utenti alcuni poteri di root limitandone altri senza consentire loro di diventare root .

Nel vostro scenario, si avrebbe bisogno di limitare l'accesso al sue passwdcomandi e il libero accesso a praticamente tutto il resto. Il problema è che non c'è niente che tu possa fare per impedire ai tuoi utenti di modificare /etc/shadow(o /etc/sudoersper quella materia) direttamente e inserire una password di root sostitutiva per dirottare root. E questo è solo lo scenario di "attacco" più semplice possibile. I sudatori con potere illimitato, tranne uno o due comandi, possono aggirare le restrizioni per dirottare l'accesso completo alla radice.

L'unica soluzione, come suggerito da SHW nei commenti, è utilizzare sudoper concedere agli utenti l'accesso a un set limitato di comandi.

Aggiornare

Potrebbe esserci un modo per ottenere questo risultato se si utilizzano i ticket Kerberos per l'autenticazione. Leggi questo documento che spiega l'uso del .k5loginfile.

Cito le parti rilevanti:

Supponiamo che l'utente alice avesse un file .k5login nella sua directory home contenente la seguente riga:
bob@FOOBAR.ORG
Ciò consentirebbe a bob di usare le applicazioni di rete Kerberos, come ssh (1), per accedere all'account di Alice, usando i ticket Kerberos di bob.
...
Si noti che poiché Bob conserva i biglietti Kerberos per il proprio principale, bob@FOOBAR.ORGnon avrebbe alcun privilegio che richieda i biglietti di Alice, come l'accesso root a nessuno degli host del sito o la possibilità di cambiare la password di Alice.

Potrei sbagliarmi, però. Sto ancora cercando la documentazione e devo ancora provare Kerberos da solo.

Suppongo che tu voglia assicurarti di avere un accesso di "admin di emergenza", anche se il tuo vero amministratore si rovina (ma a parte questo, ti fidi completamente dell'amministratore principale).

Un approccio popolare (anche se molto hacker) è quello di avere un secondo utenteuid=0 , comunemente chiamato toor(radice all'indietro). Ha una password diversa e può fungere da accesso di backup. Per aggiungere, probabilmente dovrai modificare /etc/passwde /etc/shadow(copiare le rootrighe).

È quasi sicuro, ma se devi solo evitare che l '"amministratore principale" cambi la password senza preavviso, funzionerà. Disattivare è banale, rimuovendo l' tooraccount; quindi l'unico vantaggio è avere una password separata.

In alternativa, potresti voler esaminare meccanismi di autenticazione alternativi, ad esempio sshchiavi libnss-extrausers, LDAP ecc.

Nota che l'amministratore può ancora sbagliare. Ad esempio, bloccando il firewall.

Se vuoi avere un sistema molto sicuro, prendi in considerazione l'uso di SELinux, dove anche l'utente unix (es. Root) ha un ruolo, che può essere molto più preciso. Potresti voler dare al tuo amministratore root l'accesso, ma solo un ruolo limitato (ad es. Per amministrare solo apache). Ma ciò richiederà un grande sforzo da parte tua per configurare correttamente la politica.

L'essenza di root è avere un comando illimitato del sistema. Potresti modificarlo con SELinux (un tempo c'era un sito demo in cui chiunque poteva accedere come root, ma la sua potenza era paralizzata attraverso il sistema di accesso), ma non è questo il punto. Il punto è che questa è la soluzione sbagliata al tuo problema.

Ora, non hai detto quale sia il tuo problema, ma se non ti fidi di questi utenti a tenere le mani lontane dalla password di root, non hanno attività di root. Se hanno bisogno di amministrare il webserver, o vari dispositivi hardware, o l'unità warp o altro, impostare una soluzione per questo. Crea un gruppo superpotente, dagli tutto l'accesso di cui ha bisogno e aggiungili ad esso. Se devono eseguire chiamate di sistema solo root, scrivi alcuni programmi setuid.

Naturalmente un utente con quel tipo di accesso (e un po 'di conoscenza) potrebbe probabilmente hackerare facilmente il sistema, ma almeno stai lavorando con il modello di sicurezza del sistema operativo, non contro di esso.

PS. Esistono molti modi per organizzare l'accesso root per te stesso senza la password; per uno, se ti trovi /etc/sudoers(senza restrizioni) hai solo bisogno della tua password per diventare root, ad esempio con sudo bash. Ma non dovresti semplicemente andare lì.

Probabilmente è possibile, almeno in teoria, farlo usando SELinux . Ciò consente di impostare regole molto più precise su ciò che un utente o processo è o non è autorizzato a fare. Anche con SELinux, può essere complicato rendere impossibile per un utente cambiare la password di root, ma è comunque in grado di fare tutto ciò che potrebbe essere necessario.

In realtà dipende da ciò che l'utente che non è autorizzato a modificare la password di root deve effettivamente essere in grado di fare. Probabilmente sarebbe più facile e più sicuro capire di cosa si tratta e concedere quelle autorizzazioni specificatamente usando sudo.

Forse dovresti considerare di consentire agli utenti di accedere come root a una macchina virtuale o contenitore LXC. Ciò consentirebbe loro di avere accesso completo alla radice di un sistema, senza consentire loro di impedire l'accesso all'host o l'esecuzione di azioni amministrative.

Non so che sarà praticamente fattibile, ma ecco un trucco sporco:

1. scrivere uno script / programma wrapper che copierà il /etc/passwdfile in un'altra posizione, prima di chiamare effettivosudo
2. Consenti all'utente normale di utilizzare sudo
3. Una volta terminato il suo compito o quando è uscito da sudo, ripristina il /etc/passwdfile

Lo so, ci sono molte cose più o meno che devi considerare per raggiungere questo obiettivo. Dopotutto, è un trucco sporco

L'affermazione che sudoserve solo a garantire root e che non vi è alcuna protezione dopo ciò è palesemente falsa.

Si utilizza visudoper modificare il file sudoers. Ecco una riga di esempio:

redsandro ALL=(ALL:ALL) NOPASSWD:/path/to/command

• redsandroè il nome utente a cui stiamo dando il permesso. Metti un %in primo piano per farlo applicare a un gruppo.
• ALLè un nome per questa regola. I sudatori possono fare molto di più che concedere autorizzazioni globali. Ecco dove diventa complicato però.
• = non ha bisogno di spiegazioni
• ALL:ALLlegge come (who_to_run_it_as: what_group_to_run_it_as). In questo modo è possibile consentire l'esecuzione di un comando, ma solo nel contesto di un utente o gruppo specifico.
• NOPASSWD: indica di disattivare la richiesta della password.
• /path/to/command consente di specificare comandi specifici path_to_commmand, altro_comando

La cosa da ricordare è che sebbene sudosia usato principalmente dagli utenti domestici per passare ai privilegi di root, può essere ed è usato per controllare l'accesso a comandi specifici in un modo molto più granulare.

Riferimenti

• dalla mia altra risposta qui

(Non conosco Ubuntu, ma dovrebbe essere simile a Fedora / Red-Hat)
L'unica cosa che posso immaginare limitare l'accesso alla modifica della password di root non è dare l'accesso completo alla radice, forse con sudo, o usare SElinux per limitare l'accesso al file della password ... ma non mi fiderei né di molto accesso poiché root ha generalmente accesso illimitato e potrebbe aggiornare SElinux, o rietichettare il file della password, o eseguire qualche programma pre-prepred per cambiare la password.

Se non ti fidi abbastanza di loro per non cambiare la password, probabilmente non dovresti dare loro l'accesso root. Altrimenti immagino che tu stia cercando di evitare incidenti.

Se stai solo cercando di proteggere il tuo accesso a root, imposta un programma in grado di ripristinare la password di root, quindi anche se è cambiato può essere ripristinato con un accesso minimo. (sudo fa bene da solo)

Il tuo requisito è:

Stiamo riscontrando un piccolo problema su un server [...] ovvero una garanzia che possiamo ancora accedere a quel server e diventare root indipendentemente da ciò che faranno gli altri utenti.

Dalla tua domanda sembra che tu non stia affrontando utenti malintenzionati casuali intenzionati a distruggere il tuo sistema, ma invece hanno utenti semi-fidati che possono causare malizia di tanto in tanto (forse gli studenti?). I miei suggerimenti affrontano questa situazione, non un assalto a tutto campo da parte di utenti malintenzionati.

1. Esegui il server in un ambiente virtuale. Sarai in grado di montare il filesystem del server e sostituire i file modificati con versioni note. A seconda del possibile danno che si prevede, è possibile acquisire un'istantanea di tutte le directory critiche (/ bin, / sbin, / etc, / usr, / var, ecc.) Ed espandere l'istantanea per sovrascrivere i file danneggiati lasciando il resto del sistema intatto.

2. Esegui il sistema in sola lettura, ad es. Da un DVD-R. Se riesci a vivere con la maggior parte delle parti del sistema statiche fino al prossimo riavvio, questa è una buona opzione. È inoltre possibile utilizzare un backing store di sola lettura con un ambiente virtuale o caricare il sistema di base sulla rete, rendendo le modifiche tra i riavvii molto più facili rispetto alla scrittura di un nuovo DVD-R.

3. Moduli del kernel. I Linux Security Modules (LSM) del kernel forniscono la base per la creazione di moduli sicuri. LSM è usato da SELinux, ma è anche usato da un numero di sistemi meno conosciuti e più semplici, come Smack, TOMOYO e AppArmor. Questo articolo offre una buona panoramica delle opzioni. È probabile che una di queste possa essere configurata immediatamente per impedire l'accesso in scrittura a / etc / passwd, / etc / shadow o qualsiasi altro file desiderato, anche da root.

4. La stessa idea del n. 1, ma quando il server non si trova in un ambiente virtuale. È possibile caricare il server in una catena in un sistema operativo di sola lettura come un CD live, che monta automaticamente il filesystem del server e sovrascrive il sistema di base su ogni avvio con copie note. Il sistema operativo di sola lettura si avvia quindi nel sistema operativo principale.

5. Ancora una volta, supponendo che si tratti di utenti semi-fidati che sono responsabili nei confronti di un superiore (insegnante / capo), la risposta migliore potrebbe essere Linux Audit . In questo modo conoscerai tutte le azioni rilevanti per la sicurezza e chi lo ha eseguito (saprai chi lo ha fatto perché anche se tutti gli utenti condividono l'account di root, avranno prima annullato dal proprio account utente). In effetti, potresti persino essere in grado di analizzare il registro di controllo in tempo reale e sostituire i file danneggiati. / etc / shadow sovrascritto? Nessun problema, basta che il server di monitoraggio lo sostituisca immediatamente con una versione nota.

Altre tecnologie che potresti voler esaminare in base alle tue esigenze:

• Linux Integrity Measurement Architecture / Extended Verification Module (IMA / EVM) e
• Trusted Platform Modules (TPM).

Per integrare le altre risposte, suppongo che lo scenario sia percepire la perdita del controllo di root in una situazione rara e che in quei casi sia consentito il riavvio del server. (Dopo tutto, se ritieni che la macchina sia stata compromessa, vorrai comunque metterla offline.)

Il grande vantaggio di questo è che non c'è nulla da configurare. La tua domanda diventa: " Ho dimenticato la password di root, come posso tornare indietro? " E la risposta è riavviare e scegliere la modalità utente singolo quando si accende la macchina. Questo ti dà una shell di root senza bisogno di conoscere la password. A quel punto puoi impostare una nuova password. (Oltre a recarsi e riparare eventuali danni ...)

Se cloni il tuo server in una macchina virtuale (come VirtualBox ), puoi dare accesso root illimitato alle persone e garantire comunque che avrai sempre accesso diretto alle partizioni del sistema operativo guest e quindi mantenere il controllo finale su /etc/passwde simili, dal momento che avrai root sul sistema host.

Naturalmente, fornire l'accesso root senza restrizioni potrebbe non essere ancora la soluzione giusta: se la sicurezza dei dati è un problema o una tua responsabilità, non puoi concedere l'accesso root.

Il requisito non è tecnicamente possibile. Come già eloquentemente commentato, concedere sudodiritti illimitati o persino più limitati a un utente significa che ti fidi di quell'utente. Qualcuno che ha intenzioni malvagie e sufficiente capacità tecnica e perseveranza può superare tutti gli ostacoli che vengono posti in essere.

Tuttavia, supponendo che tu possa fidarti dei tuoi utenti di non essere malvagi, puoi fare la restrizione alla modifica della password una questione di politica . È possibile creare un wrapper per il passwdprogramma che ricorderà loro "per favore non cambiare la password di root". Questo presuppone che l'origine del problema sia che gli utenti che stanno cambiando la password di root lo stanno facendo a causa di un malinteso (come forse pensare di aver cambiato la propria password dopo averlo fatto sudo bash).

In circostanze speciali (rare), se non è possibile la completa fiducia e non è possibile interrompere l' sudoaccesso a blocchi adeguati ma ragionevolmente sicuri, è possibile prendere in considerazione la possibilità di stabilire sanzioni organizzative contro la modifica della password (o qualsiasi altra forma specifica di manomissione del sistema), organizzare monitoraggio delle risorse critiche in modo che non sia facile non essere individuati per aggirare le politiche stabilite ed essere pubblici e trasparenti sulle regole di utilizzo e monitoraggio.

L'aspetto del monitoraggio e della scoperta è un problema tecnico difficile che beneficia di un'altra domanda se si sceglie di percorrere quel percorso. Mi sembra che dovremmo

1. rilevare quando un utente cambia identità in root e tenere traccia di tutti i processi creati;
2. registrare le creazioni del processo da quel momento in poi per vedere chi è l'utente originale responsabile di ciascun processo e utilizzare l'host remoto in cui gli utenti parzialmente fidati non hanno accesso per inviare i registri;
3. utilizzare una sorta di traccia del sistema per registrare ciò che sta accadendo e in seguito essere in grado di scoprire chi c'era dietro la violazione della politica.

Avremmo almeno bisogno di registrare l'apertura di un set di file diverso da quello sicuro per la scrittura, la creazione di processi exec()e, naturalmente, qualsiasi tentativo di cambiare rete.

L'implementazione potrebbe essere effettuata mediante libc modificata o (molto meglio) traccia delle chiamate di sistema.

Naturalmente, è impossibile far funzionare correttamente tale traccia e registrazione al 100%, non è facile da implementare e richiede anche risorse aggiuntive per funzionare. Ciò non impedirebbe la modifica della password o altre manomissioni indesiderate del sistema, ma renderebbe (più probabile) possibile trovare l'utente colpevole o almeno creare l'illusione che ci sia un monitoraggio e renderlo meno invitante per alcuni utenti malvagi (ma alcuni hacker che amano i problemi e vedono la fondamentale inutilità delle misure tecniche messe in atto potrebbero sentirsi incoraggiati ad accettare la sfida e cercare di aggirare il sistema solo per divertimento).

La domanda originariamente formulata è inutile. Sembra che l'obiettivo principale sia "avere ancora l'accesso", quindi parlando di un accesso di emergenza che continua a funzionare sicuramente anche con l'accesso root concesso a un'altra persona. Saluti ad Anony-Mousse che per primo l'ha notato esplicitamente.

Il problema è: se il proprietario ha accesso fisico alla scatola, può facilmente recuperare l'accesso logico al sistema (purché sia ​​ancora in vita :). In caso contrario, mantenere la password di root non salverà ad es. Da sshd o da una cattiva configurazione delle reti, quindi il sistema non è comunque accessibile.

L'argomento su come prevenire danni al sistema da parte di una persona con privilegi amministrativi sembra troppo ampio per adattarsi al formato della domanda SE.

Parlare dell'emergenza remota entra nella soluzione il modo migliore è IPMI (penso) se è disponibile. Il proprietario del sistema può collegare un'unità virtuale in qualsiasi momento, avviarlo da esso e avviare il ripristino del sistema.

Se IPMI non è disponibile, è possibile aggirare qualsiasi tecnologia di virtualizzazione adatta, come già proposto in precedenza.

Puoi limitare l'accesso a sudo nel tuo /etc/sudoersfile

Per spiegare completamente la sintassi di / etc / sudoers, useremo una regola di esempio e suddivideremo ogni colonna:

jorge  ALL=(root) /usr/bin/find, /bin/rm

La prima colonna definisce a quale utente o gruppo si applica questa regola sudo. In questo caso, è l'utente jorge. Se la parola in questa colonna è preceduta da un simbolo%, indica questo valore come gruppo anziché come utente, poiché un sistema può avere utenti e gruppi con lo stesso nome.

Il secondo valore (ALL) definisce a quali host si applica questa regola sudo. Questa colonna è particolarmente utile quando si distribuisce un ambiente sudo su più sistemi. Per un sistema Ubuntu desktop o un sistema in cui non prevedi di distribuire i ruoli sudo su più sistemi, puoi sentirti libero di lasciare questo valore impostato su ALL, che è un carattere jolly che corrisponde a tutti gli host.

Il terzo valore è impostato tra parentesi e definisce l'utente o gli utenti con cui l'utente nella prima colonna può eseguire un comando. Questo valore è impostato su root, il che significa che jorge potrà eseguire i comandi specificati nell'ultima colonna come utente root. Questo valore può anche essere impostato su TUTTI i caratteri jolly, il che consentirebbe a jorge di eseguire i comandi come qualsiasi utente sul sistema.

L'ultimo valore (/ usr / bin / find, / bin / rm) è un elenco di comandi separato da virgole che l'utente nella prima colonna può eseguire come utente (i) nella terza colonna. In questo caso, stiamo permettendo a jorge di eseguire find e rm come root. Questo valore può anche essere impostato su TUTTI i caratteri jolly, il che consentirebbe a jorge di eseguire tutti i comandi sul sistema come root.

Con questo in mente, puoi consentire i comandi X in modo delimitato da virgole e fintanto che non aggiungi passwda questo dovresti andare bene

Non esiste 1/2 root :) Una volta assegnati i privilegi di root, possono fare quello che vogliono. In alternativa puoi usare sudo per eseguire una shell bash limitata o eseguire rbash senza i privilegi di root.

Se si desidera disporre di un meccanismo di sicurezza per accedere al server come root, è possibile creare un altro utente con uid=0o creare un cron semplice che reimposti periodicamente la password di root.

Prova ad aggiungere un gruppo ruote anziché usare sudo. sudo consente a un utente di eseguire come se fosse root, il che significa che non è diverso dall'esecuzione:

su -

diventare root. La radice uid = 0; la ruota uid = 10. Le persone usano i nomi ma il sistema operativo usa l'UID. Alcuni comandi non possono essere eseguiti da un membro del gruppo di ruote. (Se usi la ruota non commetti l'errore di aggiungere root come membro del gruppo ruota). Dai un'occhiata alla documentazione di Red Hat se non sai cos'è la ruota.

Un'altra opzione è utilizzare una chiave ssh anziché una password. Supponendo che tu possa essere sicuro che le persone che usano sudo non aggiungano le loro chiavi pubbliche al file ~ / .ssh / authorizedkeys, ciò evita qualsiasi preoccupazione di cambiare la password di root perché la password di root viene effettivamente ignorata.

Se preferisci aggirare la fiducia di questi utenti (per non aggiungere la loro chiave pubblica) prova a utilizzare gli attributi di file estesi e il bit Immutable. Dopo aver creato il file ~ / .ssh / authorizedkeys e dopo aver configurato / etc / ssh / sshd_config e / etc / ssh / ssh_config, impostare il bit Immutable. Certo, ci sono anche modi per rovinare tutto: niente è perfetto.

In qualsiasi sistema, gli addetti ai lavori sono il rischio più elevato. La persona che gestisce lo spettacolo è in cima alla pila. Un pensiero correlato riguarda i contratti. Gli avvocati ti diranno "Non fare mai affari con qualcuno con cui hai bisogno di un contratto per fare affari". Il buon senso ci dice "Mai fare affari senza un contratto". Quando trovi qualcuno di cui ti fidi abbastanza per fare affari, scrivi il contratto in base alle esigenze degli altri.

Tutte le risposte inviate, compresa la mia, non riescono a indirizzare l'accesso fisico. Chiunque ce l'abbia, ha il controllo. Se non sei tu, allora c'è probabilmente un modo per ottenere la persona che accede fisicamente alla macchina nel caso in cui qualcuno trovi un modo per impedirti di accedere, o se trovano un modo per accedere anche dopo di te ho tentato di impedire che ciò accadesse. Ovviamente, se hai accesso fisico di quanto non ci sia bisogno di nessuna di queste cose, anche se l'implementazione di una coppia dovrebbe essere considerata comunque, se sei interessato a NON essere disturbato.

-John Crout

Un modo sarebbe quello di garantire che /etcnon sia scrivibile. Da nessuno, purché ci possa essere un sudoergiro.

Ciò potrebbe essere fatto montandolo sulla rete e assicurando dall'altro lato che il dispositivo non possa essere scritto.

Ciò potrebbe essere fatto utilizzando un dispositivo locale che impedisce l'accesso in scrittura ad esso. (Cerca l' write blockerhardware)

La parte importante è che la restrizione deve applicarsi al di fuori del concetto di root di quella macchina. Un hacker creativo troverà il modo di aggirare tutti gli ostacoli che metti su di essi nell'ambiente che potrebbe controllare. Quindi se root potrebbe cambiare la sua password, così può a sudoer.

Per essere sicuro che l'utente non può anche rovinare le tue abilità di accesso devi avere montato in sola lettura /bine /sbin.

E dovrai avere uno script che ripristini periodicamente la connessione di rete.

(Come un sidenote: se si consente al sudoer solo un set molto limitato di comandi e per ognuno di essi si assicura che non possano scoppiare da loro / sostituirli ecc., Quindi è possibile prevenirlo pur avendo /etcscrivibile ..)