Vraag Waarom is "chmod -R 777 /" destructief?


Dit is een Canonical Question over bestandsmachtiging en Waarom 777 is "destructief".

Ik vraag niet hoe dit probleem op te lossen, want er zijn een heleboel referenties van dat al op Server Fault (OS opnieuw installeren). Waarom doet het überhaupt iets destructiefs?

Als je ooit dit commando hebt uitgevoerd, vernietig je vrijwel onmiddellijk je besturingssysteem. Ik ben niet duidelijk waarom het verwijderen van beperkingen van invloed is op bestaande processen. Als ik bijvoorbeeld geen leestoegang tot iets heb en na een snel foutje in de terminal heb ik nu opeens toegang ... waarom zorgt Linux ervoor dat dit stuk gaat?


246
2018-02-28 21:25


oorsprong


Ik heb mijn adem inhouden toen ik deze vraag zag. - Alireza Savand


antwoorden:


Allereerst een kleine terminologie nitpick: chmod niet verwijderen toestemmingen. Het VERANDERINGEN hen.


Nu het vlees van het probleem - De modus 777 betekent: "Iedereen kan dit bestand lezen, schrijven of uitvoeren" - dat is zo toestemming gegeven voor iedereen om (effectief) te doen wat ze maar willen.

Waarom is dit slecht?

  1. U hebt zojuist iedereen laten lezen / wijzigen elk bestand op uw systeem.
    • Kus wachtwoordbeveiliging vaarwel (iedereen kan het schaduwbestand lezen en je wachtwoorden laten kraken, maar waarom moeite doen? Gewoon het wachtwoord VERANDEREN! Het is veel gemakkelijker!).
    • Kiss beveiliging voor je binaire bezigheden vaarwel (iemand kan gewoon een nieuw schrijven login programma waarmee ze elke keer binnenkomen).
    • Kus je bestanden vaarwel: één gebruiker misleidt rm -r / en het is allemaal voorbij. Het besturingssysteem kreeg de opdracht om te laten doen wat ze wilden!
  2. Je hebt pissig elk programma dat de rechten op bestanden controleert voordat je begint.
    sudo, sendmail, en een groot aantal anderen zal gewoon niet meer starten. Ze zullen de belangrijkste bestandsrechten bekijken, zien dat ze niet zijn wat ze zouden moeten zijn en een foutmelding herstellen.
    evenzo ssh zal vreselijk breken (sleutelbestanden moeten specifieke rechten hebben, anders zijn ze "onveilig" en standaard weigert SSH ze te gebruiken.)
  3. Je hebt de setuid / setgid-bits weggevaagd in de programma's die ze hadden.
    De mode 777 is eigenlijk 0777. Een van de dingen in dat leidende cijfer zijn de setuid en setgid bits.
    De meeste programma's die setuid / setgid zijn, hebben die bit ingesteld omdat ze moeten worden uitgevoerd met bepaalde privileges. Ze zijn nu kapot.
  4. Je hebt gebroken /tmp en /var/tmp Het andere ding in dat leidende octale cijfer dat nul is geworden is de sticky bit - Datgene waarin bestanden worden beschermd /tmp (en /var/tmp) kan niet worden verwijderd door mensen die deze niet bezitten.
    Er zijn (helaas) genoeg slecht gedragende scripts die "opruimen" door een rm -r /tmp/*en zonder dat het plakkerige bit is ingeschakeld /tmp  je kunt alle bestanden in die map vaarwel kussen.
    Kladbestanden verdwijnen, kan sommige slecht geschreven programma's echt van streek maken ...
  5. Je hebt grote schade aangericht /dev  /proc en soortgelijke bestandssystemen
    Dit is meer een probleem op oudere Unix-systemen waar /devis een echt bestandssysteem en de spullen die het bevat zijn speciale bestanden gemaakt met mknod, aangezien de machtigingen worden gewijzigd bij het opnieuw opstarten, maar op elk systeem waarvan de toestemmingen voor uw apparaat veranderen, kan dit aanzienlijke problemen veroorzaken, van de voor de hand liggende beveiligingsrisico's (iedereen kan elke TTY lezen) tot de minder voor de hand liggende potentiële oorzaken van een kernelpanic.
    Credit to @Tonny for pointing out this possibility
  6. Sockets en pipes kunnen breken of andere problemen hebben Sockets en leidingen kunnen volledig breken of kunnen worden blootgesteld aan schadelijke injectie als gevolg van het feit dat ze wereldwijd beschrijfbaar zijn gemaakt.
    Credit to @Tonny for pointing out this possibility
  7. U hebt elk bestand op uw systeem uitvoerbaar gemaakt
    Veel mensen hebben . in hun PATH omgevingsvariabele (dat zou je niet moeten doen!) - Dit zou een onaangename verrassing kunnen veroorzaken, omdat iedereen nu een bestand kan neerzetten dat handig als een commando wordt genoemd (zeg maar make of lsen een kans hebben om je hun kwaadwillige code te laten uitvoeren.
    Credit to @RichHomolka for pointing out this possibility
  8. Op sommige systemen chmod reset toegangscontrolelijsten (ACL's)
    Dit betekent dat je misschien moet eindigen met het opnieuw maken van al je ACL's en het overal repareren van permissies (en is een echt voorbeeld van het commando dat destructief is).
    Credit to @JamesYoungman for pointing out this possibility

Gaan de delen van het systeem die al draaien verder draaien? Waarschijnlijk al een tijdje.
Maar de volgende keer dat je een programma moet starten, of een dienst opnieuw moet opstarten, of de hemel verhoede REBOOT zal de box waarin je je bevindt voor een wereld van pijn als # 2 en # 3 hun lelijke kopjes op de voorgrond plaatsen.


335
2018-02-28 21:46



Tenminste op sommige systemen /tmp zou worden hersteld na een herstart. Hoewel er veel andere dingen lijken te zijn gebroken. Ten minste in VM die ik net heb getest lijkt een herstart de /tmp toestemmingen. Er moet ergens ergens een opstartscript zijn. - Zoredache
@Zoredache-systemen die gebruiken tmpfs meestal zelf repareren, degenen die / tmp op schijf hebben mei (afhankelijk van hun opstartscripts) - voretaq7
+1 voor het erop wijzen dat setuid en setgid zouden worden geëlimineerd. Dit is een enorm destructief aspect. Probeer te rennen find / -perms -4000 -type f en find / -perms -2000 -type f om verschillende binaire bestanden te zien die van deze vlaggen afhankelijk zijn. - Kyle Smith
Als u zoiets als "less foo.txt" typt, wordt een bestand met de naam less.txt niet uitgevoerd, ongeacht het uitvoerbare bit dat wordt ingesteld. U zou de map less.txt op uw pad moeten hebben en u zou moeten "less.txt foo.txt" typen - niet echt een toevallig iets daar. Zelfs als u de shell-aanvulling gebruikte, zou het stoppen met minder en zou u nog steeds het .txt-bestand moeten toevoegen. Om een ​​willekeurig tekstbestand met een uitvoerbare bitreeks te bellen, moet je ./nameoffile.txt gebruiken. - The Real Bill
@Deji everyone wordt gedefinieerd als het samenvoegen van een set, inclusief de gebruiker van het bestand, gebruikers in de groep die eigenaar is van het bestand en gebruikers die niet aan een van deze criteria voldoen (letterlijk de drie octale machtigingscijfers: User, Group, en Other). Met andere woorden elke gebruiker met toegang tot het systeem. ("Toegang" in deze context zou een shell-account kunnen zijn, en dat is hoe ik het normaal zou aanpakken, maar het omvat ook toegang via een webformulier / CGI die gegevens naar schijf schrijft: www gebruiker kan nu naar elk bestand op het systeem schrijven, wat betekent dat willekeurige bezoekers dat ook kunnen doen.) - voretaq7


Een belangrijk punt is dat er veel tools zoals ssh / sudo zijn die de rechten van het bestandssysteem controleren voor de belangrijkste configuratiebestanden. Als de machtigingen onjuist zijn, zijn deze hulpprogramma's ontworpen om te mislukken, omdat dit een ernstig beveiligingsprobleem zou aangeven. Op mijn Debian-testsysteem en misschien op anderen mislukt de mogelijkheid om in te loggen, waarschijnlijk omdat het inlog-binaire bestand of iets in PAM toestemmingscontroles bevat.

Dus het is niet echt dat het systeem wordt vernietigd - het is dat veel tools zijn ontworpen om onmiddellijk te falen als de toestemmingen verkeerd zijn.

Als u een systeem opnieuw opstart na het doen van een chmod 777 -R / het zal opstarten, en u kunt processen starten die geen uitdrukkelijke toestemmingscontroles hebben. Het systeem is dus niet echt dood, maar enigszins onbruikbaar met opzet.


100
2018-02-28 21:33