Men efter at have tænkt over det kan jeg ikke komme med en grund til, at delt eksekverbar kode på en intern server ikke skal have 777 tilladelser.

Fordi du stoler ikke kun på hver bruger - hvilket måske er rimeligt på en intern server, hvor "alle", der har adgang, skal have den kontrol - du stoler også på enhver proces på den server. Webserveren. SSH-serveren. DHCP-klienten. Hver planlagt opgave og enhver service. Selv processer, der kører som "ingen" og "nogroup". Alle mulige processer, der muligvis udnyttes af en angriber for at få eller udvide deres adgang.

Fordi hvis du vil være så sjusket i intern udvikling, vil nogen være så sjusket på en produktion eller kunde system, fordi "det er sådan, vi fikset det internt".

Fordi en angriber vil glæde sig over at finde det lille system, der kun er internt og ikke er vigtigt eller beskyttet, kan du se svagheder som skrivbare webapplikationsfiler, brug dem at komme ind på systemet og begynde at udnytte det for at komme et sted. Jeg vil vædde på, at de adgangskoder, som folk bruger på dette system, også fungerer på andre, mere værdifulde, interne systemer. Måske bruger I også den samme root-adgangskode på tværs af servere? Det er altid sjovt at finde.

Jeg tager andenpladsen @gowenfawr og siger, at opdræt af bedre chimpanser er et mål for sig selv her. (nu vil jeg ekstrapolere vildt om din virksomhedskultur)

Hos min softwareudviklingsvirksomhed har vi set en stigende tendens, hvor kunder beder om bevis for vores sikkerhedspraksis ikke kun i produktionsmiljøer, men også i vores udviklingsproces og virksomhedens it generelt. Dette er en helt rimelig anmodning, fordi:

1. Slurvet sikkerhed i produkter sætter deres data i fare. Se: Equifax-overtrædelse af 2017.
2. Slurvet sikkerhed i dev fører til, at udviklere skriver sjuskete produkter. Virkelig skal holdningen om, at sikkerhed er vigtig, komme fra ledelsen for at give udviklere sikkerhedstræning og tid til at foretage ordentlige kodevurderinger og viljen til at prioritere at rette sikkerhedsfejl i forhold til kundefunktioner. Tilladelse af sjusket praksis som et bevis er, at virksomhedskultur ikke fremmer sikkerhed.
3. Slurvet sikkerhedspraksis i it fører til vira i netværket, som kan føre til vira i koden. Se det berømte Linux-bagdørforsøg fra 2003, hvor nogen brød elektronisk ind i backupkodedepotet og indsatte en ondsindet kodeændring i håb om, at det til sidst ville blive flettet ind i hovedreposet.
ol>

Så er dette en beslutning, som du ville være stolt af at fortælle en kunde om?

---

Bundlinie: Princippet om mindst privilegium er en af ​​de mest grundlæggende sikre kodningsprincipper. Det er en tankegang, der skal være en del af enhver softwareudviklingsproces. Det handler om at stille spørgsmålet "Er det nødvendigt at svække vores sikkerhed som denne?" Snarere end "Kan nogen bevise, at dette er farligt?". Hackerne er altid klogere end dig.

Selvfølgelig, hvis chmod 777 er nødvendigt af en eller anden grund, så bliver det mindst privilegium, og der kunne være en legitim sikkerhedsdiskussion at have her, men det lyder som om det ikke er; dette er bare dovenskab. Det giver mig ikke tillid til, at princippet om mindst privilegium følges i selve produktet, for eksempel hvordan data lagres, hvor meget ekstra data returneres fra API-opkald, hvilke oplysninger der logges, eller hvor som helst andet princip om mindst privilegium er relevant for dit produkt.

Medmindre programmet kræver skrivetilladelser, er jeg forvirret over, hvorfor din kollega brugte chmod -R 777 / opt / path / to / shared / folder når chmod -R 775 / opt / sti / til / delt / mappe tillader stadig læsning og udførelse af tilladelser og opnå den ønskede adgang.

Da dine teammedlemmer er de eneste, der har adgang til serveren, og du stoler på dem. At have global skriveadgang er ikke nødvendigvis en dårlig ting. Men formålet er også at forhindre ondsindede eller useriøse programmer i at ændre eller slette filerne. Ransomware kan være et eksempel, der udføres af Alice med brugertilladelser.

• / home / alice / --- (drwxrwxrwx alice alice)
• / home / bob / --- (drwxrwx --- bob bob)

For ovenstående scenarie krypterer ransomware, der udføres af Alice, og overskrive alle filer, hun har skriveadgang til. Givet Alice hører ikke til gruppen bob og / home / bob / har ikke global rwx Alice har nul adgang. Men hvis Bob skulle køre ransomware med brugertilladelser, har Bob rwx -tilladelser, fordi / home / alice / bruger globale rwx -tilladelser. Så nu bliver både Alice og Bobs hjemmekataloger krypteret af ransomware.

Tilføjelse af brugere til en gruppe er ret simpelt, Linux: Føj bruger til gruppe (Primær / Sekundær / Ny / Eksisterende). Dette tilføjer brugernavnet: alice til gruppen bob . Chown -R bob: bob hvor bruger: gruppe ejer kataloget rekursivt. chmod -R 750 vil rekursivt give rwxr-x --- tilladelser, så Alice kan læse og udføre i / home / bob / -mappen, men kan ikke skrive.

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

Princippet om mindst adgang er primært at beskytte mod ondsindede brugere. Imidlertid er ondsindede programmer også meget alvorlige. Derfor er global læsning, skrivning og udførelse sammen ------ rwx et meget dårligt sikkerhedsprincip. Denne idé gøres ved at tilføje alice til gruppen bob . Nu har brugeren alice rx tilladelser til / home / bob / mens andre brugere uden for bob -gruppen ikke kan, undtagen rod. Ligeledes, hvis Bob ønskede at dele filer med Alice, men ikke ønsker, at Alice skulle have gruppeadgang, kunne der oprettes en ny gruppe, kaldet AB , hvor Alice og Bob er i gruppen. Nu kunne der oprettes en mappe / opt / AB_share / (rwxrwx ---) , og ovenstående kommandoer blev anvendt. Kun dem inden for AB -gruppen har adgang.