Motivo per non utilizzare chmod -R 777 sul server interno per il codice sorgente del progetto?

However, after putting some thought into it I can't come up with a reason why shared executable code on an internal server shouldn't have 777 permissions.

Perché non ci si fida solo di tutti gli utenti, il che potrebbe essere ragionevole su un server interno in cui "tutti" che hanno accesso dovrebbero avere quel controllo - anche a te si fida di ogni processo su quel server. Il server web. Il server SSH. Il client DHCP. Ogni compito programmato e ogni servizio. Anche i processi in esecuzione come "nessuno" e "nogroup". Tutti i tipi di processi che potrebbero essere sfruttati da un utente malintenzionato per ottenere o espandere il proprio accesso.

Perché se hai intenzione di essere così sciatto nello sviluppo interno, qualcuno sarà così sciatto su un sistema di produzione o di un cliente, perché "è così che lo abbiamo risolto internamente".

Poiché un utente malintenzionato si rallegra nel trovare quel piccolo sistema che è solo interno e non è importante o protetto, vedere punti deboli come i file di applicazioni Web scrivibili, utilizzarli per entrare nel sistema e iniziare a sfruttarlo per ottenere da qualche parte. Scommetto che le password che le persone usano su quel sistema lavorano anche su altri sistemi interni più preziosi. Forse voi ragazzi usate la stessa password di root anche tra i server? È sempre divertente da trovare.

Vado secondo @gowenfawr e dico che allevare scimpanzè migliori è un obiettivo a sé stante qui. (ora estrapolerò in modo esagerato la tua cultura aziendale)

Nella mia società di sviluppo software, stiamo assistendo a una crescente tendenza dei clienti che richiedono 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é:

1. La scarsa sicurezza in prod mette a rischio i propri dati. Vedi: Equifax violazione del 2017 .
2. La scarsa sicurezza negli sviluppatori porta gli sviluppatori a scrivere prodotti sciatti. In realtà, tuttavia, l'atteggiamento che la sicurezza è importante deve venire dal management per dare agli sviluppatori formazione sulla sicurezza e tempo per fare le revisioni corrette del codice e la volontà di dare la priorità alla risoluzione dei difetti di sicurezza sulle caratteristiche del cliente. Consentendo pratiche sciatte come è la prova che la cultura aziendale non promuove la sicurezza.
3. Le pratiche di sicurezza scarse nell'IT portano a virus nella rete che possono portare a virus nel codice. Vedi il famoso tentativo di backdoor Linux del 2003 dove qualcuno ha fatto irruzione elettronicamente nel repository del codice di backup e ha inserito un codice maligno, sperando che alla fine si sarebbe fuso nel repository principale.

Quindi questa è una decisione che vorresti dire a un cliente?

In conclusione: il principio del privilegio minimo è uno dei principi fondamentali per la codifica sicura. È una mentalità che dovrebbe essere parte di qualsiasi processo di sviluppo del 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 ragione, allora diventa il privilegio minimo, e qui potrebbe esserci una discussione sulla sicurezza legittima, ma sembra che non ci sia; questa è solo pigrizia. Ciò non mi dà la certezza che il principio del minimo privilegio viene seguito nel prodotto stesso, ad esempio in che modo vengono archiviati i dati, quanti dati extra vengono restituiti dalle chiamate API, quali informazioni vengono registrate, o ovunque il principio del privilegio minimo è rilevante per il tuo prodotto.

A meno che il programma non richieda permessi di scrittura, sono confuso sul motivo per cui il tuo collaboratore ha utilizzato chmod -R 777 /opt/path/to/shared/folder quando chmod -R 775 /opt/path/to/shared/folder avrebbe comunque permesso di leggere ed eseguire le autorizzazioni e ottenere l'accesso desiderato.

Dato che i membri del tuo team sono gli unici con accesso al server e tu ti fidi di loro. Avere accesso globale alla scrittura non è necessariamente una cosa negativa. Ma lo scopo è anche quello di impedire ai programmi maliziosi o canaglia di modificare o cancellare i file. Il ransomware potrebbe essere un esempio, che viene eseguito da Alice, con le autorizzazioni 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 sovrascriverà tutti i file a cui deve accedere in scrittura. Dato che Alice non appartiene al gruppo bob e /home/bob/ non ha globale rwx Alice ha accesso zero. Tuttavia, se Bob doveva eseguire il ransomware con autorizzazioni utente, Bob ha autorizzazioni rwx perché /home/alice/ utilizza le autorizzazioni globali rwx . Quindi, ora sia le directory home di Alice che quelle di Bob verranno crittografate dal ransomware.

Aggiungere utenti a un gruppo è abbastanza semplice, Linux: Aggiungi utente al gruppo ( primario secondario / Nuovo / esistente) /. Questo aggiungerà il nome utente: alice , al gruppo bob . Chown -R bob:bob dove user:group possiede la directory, in modo ricorsivo. chmod -R 750 fornirà ricorsivamente le autorizzazioni rwxr-x--- , quindi Alice può leggere ed eseguire all'interno della directory /home/bob/ , ma non può scrivere.

• sudo adduser alice bob
• sudo chown -R bob:bob /home/bob/
• sudo chmod -R 750 /home/bob/

Il principio del minimo accesso è principalmente la protezione da utenti malintenzionati. Tuttavia, i programmi maligni sono anche una preoccupazione molto seria. Questo è il motivo per cui la lettura globale, la scrittura e l'esecuzione, insieme, ------rwx sono un pessimo principio di sicurezza. Questa idea viene eseguita aggiungendo alice al gruppo bob . Ora l'utente alice ha le autorizzazioni r-x a /home/bob/ mentre gli altri utenti al di fuori del gruppo bob non possono, ad eccezione di root. Allo stesso modo, se Bob desiderava condividere file con Alice, ma non desidera che Alice abbia accesso al gruppo, un nuovo gruppo, chiamato AB , nel quale potrebbero essere creati Alice e Bob nel gruppo. Ora è possibile creare una directory /opt/AB_share/ (rwxrwx---) e applicare i comandi precedenti. Solo quelli all'interno del gruppo AB avrebbero accesso.