Tuttavia, dopo averci riflettuto un po', non riesco a trovare un motivo per cui il codice eseguibile condiviso su un server interno non dovrebbe avere autorizzazioni 777.
Poiché non ti fidi solo di ogni utente, il che potrebbe essere ragionevole su un server interno in cui "tutti" che hanno accesso dovrebbero avere quel controllo, ti fidi anche di ogni processo su quel server. Il server web. Il server SSH. Il client DHCP. Ogni attività pianificata e ogni servizio. Anche i processi in esecuzione come "nobody" e "nogroup". Tutti i tipi di processi che potrebbero essere sfruttati da un utente malintenzionato per ottenere o espandere il proprio accesso.
Perché se sarai così sciatto nello sviluppo interno, qualcuno sarà così sciatto su un sistema di produzione o cliente, perché "è così che l'abbiamo risolto internamente".
Perché un utente malintenzionato si diletterà nel trovare quel piccolo sistema che è solo interno e non è importante o protetto, vedere punti deboli come file di applicazioni web scrivibili, usarli per entrare nel sistema e iniziare a sfruttarlo per arrivare da qualche parte. Scommetto che le password che le persone usano su quel sistema funzionano anche su altri sistemi interni più preziosi. Forse voi ragazzi usate la stessa password di root anche su tutti i server? È sempre divertente da trovare.
Asseconderò @gowenfawr e dirò che allevare scimpanzé migliori è un obiettivo a sé stante qui. (ora estrapolerò selvaggiamente la tua cultura aziendale)
Nella mia società di sviluppo software, abbiamo assistito a una tendenza crescente dei clienti che chiedono prove delle nostre pratiche di sicurezza non solo negli ambienti di produzione, ma anche nel nostro processo di sviluppo e nell'IT aziendale in generale. Questa è una richiesta perfettamente ragionevole perché:
- La scarsa sicurezza nella produzione mette a rischio i loro dati. Vedi:Violazione di Equifax del 2017.
- La sicurezza sciatta nello sviluppo porta gli sviluppatori a scrivere prodotti sciatti. In realtà, però, l'atteggiamento secondo cui la sicurezza è importante deve provenire dalla direzione per fornire agli sviluppatori formazione sulla sicurezza e tempo per eseguire adeguate revisioni del codice e la volontà di dare la priorità alla correzione dei difetti di sicurezza rispetto alle funzionalità del cliente. Consentire pratiche sciatte come è la prova che la cultura aziendale non promuove la sicurezza.
- Pratiche di sicurezza sciatte nell'IT portano a virus nella rete che possono portare a virus nel codice. Guarda il famoso tentativo di backdoor di Linux del 2003 in cui qualcuno è entrato elettronicamente nel repository del codice di backup e ha inserito una modifica al codice dannoso, sperando che alla fine venisse unito al repository principale.
Quindi è una decisione di cui saresti orgoglioso di parlare a un cliente?
In conclusione: Il principio del privilegio minimo è uno dei principi di codifica sicura più fondamentali. È una mentalità che dovrebbe far parte di qualsiasi processo di sviluppo software. Si tratta di porre la domanda "È necessario indebolire la nostra sicurezza in questo modo?", piuttosto che "Qualcuno può dimostrare che questo è pericoloso?". Gli hacker sono sempre più intelligenti di te.
Ovviamente se chmod 777 è necessario per qualche motivo, allora diventa il privilegio minimo, e qui potrebbe esserci una legittima discussione sulla sicurezza, ma sembra che non ci sia; questa è solo pigrizia. Ciò non mi dà fiducia che il principio del privilegio minimo venga seguito nel prodotto stesso, ad esempio come vengono archiviati i dati, quanti dati extra vengono restituiti dalle chiamate API, quali informazioni vengono registrate o ovunque sia il principio del privilegio minimo pertinenti al tuo prodotto.
A meno che il programma non richieda permessi di scrittura, sono confuso sul perché il tuo collega abbia usato chmod -R 777 /opt/path/to/shared/folder quando chmod -R 775 /opt/path/to/shared/folder consentirebbe comunque i permessi di lettura ed esecuzione e otterrebbe l'accesso desiderato.
Dato che i membri del tuo team sono gli unici con accesso al server e ti fidi di loro. Avere accesso in scrittura globale non è necessariamente una cosa negativa. Ma lo scopo è anche impedire a programmi dannosi o canaglia di modificare o eliminare i file. Un ransomware potrebbe essere un esempio, che viene eseguito da Alice, con i permessi dell'utente.
- /home/alice/ --- (drwxrwxrwx alice alice)
- /home/bob/ --- (drwxrwx--- bob bob)
Per lo scenario di cui sopra, il ransomware eseguito da Alice crittograferebbe e sovrascriverebbe tutti i file a cui deve accedere in scrittura. Dato che Alice non appartengono al gruppo bob e /home/bob/ non ha rwx globale Alice non ha accesso. Tuttavia, se Bob dovesse eseguire il ransomware con le autorizzazioni utente, Bob ne avrebbe rwx autorizzazioni perché /home/alice/ utilizza rwx globale autorizzazioni. Quindi, ora entrambe le home directory di Alice e Bob verranno crittografate dal ransomware.
Aggiungere utenti a un gruppo è abbastanza semplice, Linux:aggiungi utente a gruppo (primario/secondario/nuovo/esistente). Questo aggiungerà il nome utente:alice , al bob gruppo. Chown -R bob:bob dove user:group possiede la directory, in modo ricorsivo. chmod -R 750 fornirà ricorsivamente rwxr-x--- autorizzazioni, in modo che Alice possa leggere ed eseguire all'interno di /home/bob/ directory, ma non può scrivere.
sudo adduser alice bobsudo chown -R bob:bob /home/bob/sudo chmod -R 750 /home/bob/
Il principio dell'accesso minimo è principalmente quello di proteggere dagli utenti malintenzionati. Tuttavia, anche i programmi dannosi sono una preoccupazione molto seria. Questo è il motivo per cui lettura, scrittura ed esecuzione globali, insieme ------rwx è un pessimo principio di sicurezza. Questa idea viene realizzata aggiungendo alice al bob gruppo. Ora l'utente alice ha r-x autorizzazioni a /home/bob/ mentre altri utenti al di fuori di bob il gruppo non può, tranne root. Allo stesso modo, se Bob volesse condividere file con Alice, ma non vuole che Alice abbia accesso al gruppo, un nuovo gruppo, chiamato AB dove Alice e Bob sono nel gruppo potrebbe essere creato. Ora una directory /opt/AB_share/ (rwxrwx---) potrebbe essere creato e applicare i comandi precedenti. Solo quelli all'interno di AB gruppo avrebbe accesso.