เหตุใดจึงเป็น "chmod -R 777 /" การทำลาย

255

นี่เป็นคำถามที่ยอมรับได้เกี่ยวกับการอนุญาตของไฟล์และทำไม 777 ถึงเป็น "การทำลายล้าง"

ฉันไม่ได้ถามว่าจะแก้ไขปัญหานี้ได้อย่างไรเนื่องจากมีการอ้างอิงจำนวนมากใน Server Fault แล้ว (ติดตั้งระบบปฏิบัติการใหม่) ทำไมมันถึงทำสิ่งใดทำลายได้ทั้งหมด?

หากคุณเคยรันคำสั่งนี้คุณจะทำลายระบบปฏิบัติการของคุณทันที ฉันไม่ชัดเจนว่าทำไมการลบข้อ จำกัด มีผลกระทบต่อกระบวนการที่มีอยู่ ตัวอย่างเช่นถ้าฉันไม่ได้อ่านการเข้าถึงบางสิ่งบางอย่างและหลังจากพิมพ์ผิด ๆ ในเทอร์มินัลในทันใดฉันก็สามารถเข้าถึงได้อย่างดีแล้ว ... ทำไมลินุกซ์ถึงพังล่ะ?

linux permissions chmod

— แซมไวส์
แหล่งที่มา

ฉันกลั้นหายใจเมื่อเห็นคำถามนี้

— Alireza Savand

344

ก่อนอื่นคำศัพท์เล็กน้อย nitpick: chmodไม่ลบสิทธิ์ มันเปลี่ยนพวกเขา

ตอนนี้เนื้อเรื่องของปัญหา - โหมด777หมายถึง "ทุกคนสามารถอ่านเขียนหรือเรียกใช้ไฟล์นี้" - คุณได้อนุญาตให้ทุกคนทำ (อย่างมีประสิทธิภาพ) ตามที่พวกเขาต้องการ

ทีนี้ทำไมมันถึงไม่ดี?

คุณเพียงแค่ให้ทุกคนอ่าน / แก้ไขไฟล์ทุกไฟล์ในระบบของคุณ
- บอกลาการรักษาความปลอดภัยด้วยรหัสผ่าน (ทุกคนสามารถอ่านไฟล์เงาและถอดรหัสรหัสผ่านของคุณได้ แต่ทำไมต้องกังวล? เพียงแค่เปลี่ยนรหัสผ่าน! มันง่ายกว่ามาก!)
- จูบการรักษาความปลอดภัยสำหรับลาก่อนไบนารีของคุณ (บางคนสามารถเขียนloginโปรแกรมใหม่ที่ให้พวกเขาทุกครั้ง)
- บอกลาไฟล์ของคุณ: ผู้ใช้หนึ่งคนนำทางผิดrm -r /และจบลงแล้ว ระบบปฏิบัติการบอกว่าให้พวกเขาทำสิ่งที่พวกเขาต้องการ!
คุณได้ปิดทุกโปรแกรมที่ตรวจสอบการอนุญาตไฟล์ก่อนที่จะเริ่ม
sudo, sendmailและโฮสต์ของผู้อื่นก็จะไม่เริ่มต้นอีกต่อไป พวกเขาจะตรวจสอบการอนุญาตไฟล์สำคัญดูว่าไม่ใช่สิ่งที่ควรจะเป็นและกลับมาแสดงข้อผิดพลาด
ในทำนองเดียวกันsshจะทำลายอย่างน่ากลัว (ไฟล์สำคัญต้องมีสิทธิ์เฉพาะมิฉะนั้นพวกเขาจะ "ไม่ปลอดภัย" และโดยค่าเริ่มต้น SSH จะปฏิเสธที่จะใช้พวกเขา)
คุณลบบิต setuid / setgid ของโปรแกรมที่มีมาให้
โหมดเป็นจริง777 ในบรรดาสิ่งต่าง ๆ ในเลขนำหน้าคือและบิต โปรแกรมส่วนใหญ่ที่ setuid / setgid มีการตั้งค่าบิตนั้นเพราะพวกเขาจะต้องทำงานด้วยสิทธิ์พิเศษบางอย่าง พวกเขาเสียแล้ว0777setuidsetgid
คุณแตก/tmpแล้ว/var/tmp อีกอย่างในเลขฐานแปดหลักที่เป็นศูนย์คือsticky bit- สิ่งที่ปกป้องไฟล์ใน/tmp(และ/var/tmp) จากการถูกลบโดยผู้ที่ไม่ได้เป็นเจ้าของ
มี (น่าเสียดาย) สคริปต์ที่มีพฤติกรรมไม่ดีมากมายออกมาที่นั่น "ล้างข้อมูล" โดยการทำrm -r /tmp/*และโดยไม่ติดตั้งบิตเหนียว/tmp คุณสามารถจูบไฟล์ทั้งหมดในไดเรกทอรีที่ลา
การลบไฟล์เริ่มต้นหายไปอาจทำให้โปรแกรมที่เขียนไม่ดี ...
คุณได้ก่อให้เกิดความเสียหายใน/dev /procระบบไฟล์ที่คล้ายกัน
นี่เป็นปัญหาของระบบ Unix ที่เก่ากว่าซึ่ง/devเป็นระบบไฟล์จริงและสิ่งที่มีอยู่นั้นเป็นไฟล์พิเศษที่สร้างขึ้นmknodเนื่องจากการเปลี่ยนแปลงการอนุญาตจะถูกสงวนไว้สำหรับการรีบูต แต่ในระบบใด ๆ การอนุญาตให้อุปกรณ์ของคุณเปลี่ยนอาจทำให้เกิดปัญหามากมายตั้งแต่ความเสี่ยงด้านความปลอดภัยที่ชัดเจน (ทุกคนสามารถอ่าน TTY ทุกครั้ง) ไปจนถึงสาเหตุที่อาจเกิดความไม่ชัดเจนของ kernel panic
Credit to @Tonny for pointing out this possibility
ซ็อกเก็ตและท่ออาจแตกหรือมีปัญหาอื่น ๆ ซ็อกเก็ตและท่ออาจแตกทั้งหมดหรือสัมผัสกับการฉีดที่เป็นอันตรายอันเป็นผลมาจากการที่โลกเขียนได้
Credit to @Tonny for pointing out this possibility
คุณได้ทำไฟล์ในระบบของคุณทุกที่ปฏิบัติการ
ผู้คนจำนวนมากมี.ในพวกเขาPATHตัวแปรสภาพแวดล้อม (ที่คุณไม่ควร!) - ซึ่งอาจก่อให้เกิดความประหลาดใจที่ไม่พึงประสงค์ในขณะนี้ทุกคนสามารถวางไฟล์ที่ชื่อว่าสิ่งอำนวยความสะดวกเช่นคำสั่ง (พูดmakeหรือlsและ มี shot ที่ช่วยให้คุณเรียกใช้รหัสที่เป็นอันตราย
Credit to @RichHomolka for pointing out this possibility
ในบางระบบchmodจะรีเซ็ตรายการควบคุมการเข้าถึง (ACLs)
ซึ่งหมายความว่าคุณอาจเลิกล้มต้องสร้าง ACL ทั้งหมดของคุณใหม่นอกเหนือจากการแก้ไขการอนุญาตทุกที่ (และเป็นตัวอย่างที่แท้จริงของคำสั่งที่ถูกทำลาย)
Credit to @JamesYoungman for pointing out this possibility

ส่วนต่าง ๆ ของระบบที่ทำงานอยู่จะยังคงทำงานต่อไป อาจเป็นไปได้สักพักหนึ่ง
แต่ในครั้งต่อไปที่คุณต้องเปิดโปรแกรมหรือเริ่มบริการใหม่หรือสวรรค์ห้าม REBOOT กล่องที่คุณกำลังเข้าสู่โลกแห่งความเจ็บปวดเนื่องจาก # 2 และ # 3 ข้างต้นจะทำให้หัวของพวกเขาน่าเกลียด

— voretaq7
แหล่งที่มา

อย่างน้อยในบางระบบ/tmpจะได้รับการแก้ไขหลังจากรีบูต แม้ว่าทุกสิ่งอื่น ๆ มากมายดูเหมือนว่าจะถูกทำลาย อย่างน้อยใน VM ฉันเพิ่งทดสอบมันปรากฏรีบูตคง/tmpสิทธิ์ จะต้องมีบางอย่างในสคริปต์เริ่มต้นที่ไหนสักแห่ง

— Zoredache

@Zoredache ระบบที่ใช้tmpfsมักจะแก้ไขตัวเองคนที่มี / tmp บนดิสก์อาจ (ขึ้นอยู่กับสคริปต์เริ่มต้นของพวกเขา)

— voretaq7

+1 สำหรับการชี้ให้เห็นว่า setuid และ setgid จะถูกกำจัด นี่คือลักษณะการทำลายล้างอย่างมหาศาล ลองวิ่งfind / -perms -4000 -type fและfind / -perms -2000 -type fดูไบนารีต่าง ๆ ที่พึ่งพาธงเหล่านี้

— Kyle Smith

การพิมพ์บางอย่างเช่น "less foo.txt" จะไม่เรียกใช้ไฟล์ที่ชื่อว่า less.txt โดยไม่คำนึงถึงบิตที่เรียกใช้งานได้ซึ่งถูกตั้งค่าไว้ คุณจะต้องมีไดเรกทอรี less.txt อยู่ในเส้นทางของคุณและคุณจะต้องพิมพ์ "less.txt foo.txt" - ไม่ใช่สิ่งที่บังเอิญเกิดขึ้นจริง แม้ว่าคุณจะใช้การทำให้เชลล์สมบูรณ์ แต่ก็จะหยุดทำงานน้อยลง ในการโทรหาไฟล์ข้อความแบบสุ่มที่มีชุดไฟล์เรียกทำงานบิตที่คุณต้องใช้

— ตั๋วเงินจริง

@Deji everyoneถูกกำหนดให้เป็นสหภาพของชุดรวมทั้งผู้ใช้ที่เป็นเจ้าของไฟล์ที่ผู้ใช้ในกลุ่มซึ่งเป็นเจ้าของแฟ้มและผู้ใช้ที่ไม่ได้ตอบสนองอย่างใดอย่างหนึ่งของเกณฑ์เหล่านั้น (ตัวอักษรตัวเลขสามได้รับอนุญาตฐานแปด: User, GroupและOther) กล่าวอีกนัยหนึ่งคือผู้ใช้ทุกคนที่สามารถเข้าถึงระบบได้ ("การเข้าถึง" ในบริบทนี้อาจเป็นบัญชีเชลล์ซึ่งเป็นวิธีที่ปกติฉันจะจัดการมัน แต่มันรวมถึงการเข้าถึงผ่านเว็บฟอร์ม / CGI ที่เขียนข้อมูลไปยังดิสก์: wwwผู้ใช้สามารถเขียนไฟล์ใด ๆ ในระบบ ซึ่งหมายความว่าผู้เข้าชมแบบสุ่มสามารถทำได้เช่นกัน)

— voretaq7

102

สิ่งสำคัญอย่างหนึ่งคือมีเครื่องมือมากมายเช่น ssh / sudo ที่ตรวจสอบการอนุญาตของระบบไฟล์สำหรับไฟล์ config ที่สำคัญ หากการอนุญาตไม่ถูกต้องเครื่องมือเหล่านี้ได้รับการออกแบบให้ล้มเหลวเนื่องจากจะเป็นการระบุถึงปัญหาด้านความปลอดภัยที่ร้ายแรง ในระบบทดสอบ Debian ของฉันและบางทีในคนอื่น ๆ ความสามารถในการเข้าสู่ระบบล้มเหลวอาจเป็นเพราะไบนารีเข้าสู่ระบบหรือบางสิ่งใน PAM มีการตรวจสอบสิทธิ์

ดังนั้นไม่ใช่ว่าระบบจะถูกทำลายจริง ๆ - เป็นเครื่องมือที่ออกแบบมาให้ล้มเหลวทันทีเมื่อสิทธิ์ผิด

หากคุณรีบู๊ตระบบหลังจากทำchmod 777 -R /แล้วระบบจะบู๊ตและคุณสามารถเริ่มกระบวนการที่ไม่มีการตรวจสอบสิทธิ์อย่างชัดเจน ดังนั้นระบบจึงไม่ตายจริง ๆ เพียงแค่ใช้การออกแบบไม่ได้เลย

— Zoredache
แหล่งที่มา