Nicméně poté, co jsem se nad tím zamyslel, nemohu přijít na oblasti, proč by sdílený spustitelný kód na interním serveru neměl mít oprávnění 777.
Protože nejenže důvěřujete každému uživateli – což může být rozumné na interním serveru, kde by tuto kontrolu měl mít „každý“, kdo má přístup – důvěřujete také každému procesu na tomto serveru. Webový server. SSH server. Klient DHCP. Každý naplánovaný úkol a každá služba. Dokonce i procesy běžící jako „nobody“ a „nogroup“. Všechny druhy procesů, které by mohl útočník využít k získání nebo rozšíření svého přístupu.
Protože pokud budete tak nedbalí v interním vývoji, někdo bude tak nedbalý v produkčním nebo zákaznickém systému, protože „tak jsme to interně opravili“.
Protože útočníka potěší, když najde ten malý systém, který je pouze interní a není důležitý ani chráněný, uvidí slabiny, jako jsou zapisovatelné soubory webových aplikací, použije je k tomu, aby se dostal do systému a začal ho využívat, aby se někam dostal. Vsadím se, že hesla, která lidé používají v tomto systému, fungují i na jiných, hodnotnějších, interních systémech. Možná také používáte stejné heslo root na serverech? To je vždy zábavné najít.
Budu sekundovat @gowenfawr a řeknu, že chov lepších šimpanzů je zde cílem sám o sobě. (nyní budu divoce extrapolovat o vaší firemní kultuře)
V mé společnosti zabývající se vývojem softwaru jsme svědky rostoucího trendu zákazníků požadujících důkazy o našich bezpečnostních postupech nejen v produkčním prostředí, ale také v našem vývojovém procesu a podnikovém IT obecně. Toto je naprosto rozumný požadavek, protože:
- Nepatrné zabezpečení v produktu ohrožuje jejich data. Viz:Porušení služby Equifax z roku 2017.
- Nepatrné zabezpečení ve vývoji vede k tomu, že vývojáři píší nedbalé produkty. Ve skutečnosti však postoj, že bezpečnost je důležitá, musí přijít od vedení, aby vývojářům poskytlo bezpečnostní školení a čas na provedení řádných kontrol kódu a ochotu upřednostnit opravu bezpečnostních chyb před funkcemi zákazníků. Povolení nedbalých praktik jako je důkaz, že firemní kultura nepodporuje bezpečnost.
- Nepatrné bezpečnostní postupy v IT vedou k virům v síti, které mohou vést k virům v kódu. Podívejte se na slavný pokus o zadní vrátka Linuxu z roku 2003, kdy se někdo elektronicky vloupal do úložiště záložního kódu a vložil změnu škodlivého kódu v naději, že bude nakonec začleněn do hlavního úložiště.
Je to tedy rozhodnutí, o kterém byste byli hrdí, kdyby jste o něm řekli zákazníkovi?
Sečteno a podtrženo: Princip nejmenšího privilegia je jedním z nejzákladnějších principů bezpečného kódování. Je to způsob myšlení, který by měl být součástí jakéhokoli procesu vývoje softwaru. Jde o to položit si otázku „Je nutné takto oslabovat naši bezpečnost?“, spíše než „Může někdo dokázat, že je to nebezpečné?“. Hackeři jsou vždy chytřejší než vy.
Samozřejmě pokud chmod 777 je z nějakého důvodu nezbytná, pak se stává nejmenším privilegiem a mohla by zde proběhnout legitimní diskuse o bezpečnosti, ale zní to, jako by tomu tak nebylo; tohle je jen lenost. To mi nedává jistotu, že v samotném produktu je dodržován princip nejmenšího privilegia, například jak se ukládají data, kolik dat navíc se vrací z volání API, jaké informace jsou protokolovány nebo kdekoli jinde je princip nejmenšího privilegia relevantní pro váš produkt.
Pokud program nevyžaduje oprávnění k zápisu, jsem zmatený, proč váš spolupracovník použil chmod -R 777 /opt/path/to/shared/folder když chmod -R 775 /opt/path/to/shared/folder by stále umožňovalo oprávnění ke čtení a spouštění a dosáhlo požadovaného přístupu.
Vzhledem k tomu, že členové vašeho týmu jsou jediní, kdo mají přístup k serveru, a důvěřujete jim. Mít globální přístup pro zápis není nutně špatná věc. Účelem je však také zabránit škodlivým nebo nepoctivým programům v úpravě nebo mazání souborů. Příkladem může být ransomware, který spouští Alice s uživatelskými oprávněními.
- /home/alice/ --- (drwxrwxrwx alice alice)
- /home/bob/ --- (drwxrwx--- bob bob)
Ve výše uvedeném scénáři by ransomware spuštěný Alicí zašifroval a přepsal všechny soubory, ke kterým má přístup pro zápis. Daná Alice ne patří do skupiny bob a /home/bob/ nemá globální rwx Alice má nulový přístup. Pokud by však měl Bob spouštět ransomware s uživatelskými oprávněními, má Bob rwx oprávnění, protože /home/alice/ používá globální rwx oprávnění. Takže nyní budou domovské adresáře Alice i Boba šifrovány ransomwarem.
Přidání uživatelů do skupiny je poměrně jednoduché, Linux:Přidat uživatele do skupiny (Primární/Sekundární/Nový/Existující). Tím se přidá uživatelské jméno:alice , na bob skupina. Chown -R bob:bob kde user:group vlastní adresář, rekurzivně. chmod -R 750 bude rekurzivně poskytovat rwxr-x--- oprávnění, takže Alice může číst a spouštět do /home/bob/ adresář, ale nelze zapisovat.
sudo adduser alice bobsudo chown -R bob:bob /home/bob/sudo chmod -R 750 /home/bob/
Princip nejmenšího přístupu spočívá především v ochraně před uživateli se zlými úmysly. Velmi vážným problémem jsou však také škodlivé programy. To je důvod, proč globální čtení, zápis a spouštění společně ------rwx je velmi špatný bezpečnostní princip. Tento nápad se provádí přidáním alice na bob skupina. Nyní uživatel alice má r-x oprávnění k /home/bob/ zatímco ostatní uživatelé mimo bob skupina nemůže, kromě root. Stejně tak, pokud Bob chtěl sdílet soubory s Alicí, ale nechce, aby Alice měla skupinový přístup, nová skupina nazvaná AB kde jsou Alice a Bob ve skupině, by mohlo být vytvořeno. Nyní adresář /opt/AB_share/ (rwxrwx---) lze vytvořit a použít výše uvedené příkazy. Pouze ty v rámci AB skupina bude mít přístup.