เหตุใดไฟล์ที่เรียกทำงานได้ในเช่น / usr / sbin สามารถเขียนได้โดย root?

คุณช่วยอธิบายได้ไหมว่าทำไมไฟล์คอมไพล์ไบนารี (ตัวอย่างเช่น/usr/sbin) มีสิทธิ์ในการเขียนสำหรับrootผู้ใช้

สำหรับฉันมันถูกรวบรวม หมายความว่าการเขียนโดยตรงนั้นไม่มีประโยชน์และอาจทำให้ไฟล์มีปัญหาด้านความปลอดภัยบางประการ

สคริปต์ (เช่นbashไฟล์) อาจเขียนได้เพราะมันเป็นไฟล์ข้อความโดยทั่วไป แต่ทำไมมันจึงเป็นแบบเดียวกันสำหรับไฟล์ที่คอมไพล์โดยที่ไม่จำเป็นต้องเขียนจริง ๆ เท่าที่ฉันรู้

ขอบคุณล่วงหน้าสำหรับความคิดเห็นของคุณ

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

เพื่อชี้แจงคุณสงสัยว่าทำไมผู้ใช้rootมีสิทธิ์เขียนไปยังไฟล์ไบนารี? หากไม่มีอะไรอื่นมันจะช่วยได้เมื่ออัพเกรดแพ็คเกจ

— Eric Renouf

โปรดทราบว่าไฟล์ไบนารีแดกดันเป็นไฟล์เดียวที่เราเขียน / แก้ไขโดยตรงบนดิสก์ เราไม่สามารถทำได้ด้วยไฟล์ข้อความเช่นสคริปต์เนื่องจากการแก้ไขข้อความเกี่ยวข้องกับการไม่เขียนลงไฟล์ แต่เพิ่มไบต์พิเศษที่อยู่ตรงกลางของไฟล์หรือลบไบต์ที่อยู่ตรงกลางของไฟล์ นี่เป็นไปไม่ได้ที่จะทำกับ fseek fwrite ดังนั้นสำหรับไฟล์ข้อความเราปกติอ่าน RAM แล้วลบไฟล์เก่าและเขียนเนื้อหาของ RAM ไปยังดิสก์ (เช่นเราเขียนทับ) นอกจากนี้เมื่อคุณติดตั้งย้ายหรือแทนที่ไฟล์ปฏิบัติการคุณกำลังเขียนลงดิสก์ดังนั้นคุณต้องมีสิทธิ์ในการเขียน

— slebetman

@slebetman: คุณสามารถแก้ไขไฟล์ข้อความได้โดยตรง ตัวอย่างเช่นเปิดไฟล์ขยายไฟล์แม็พหน่วยความจำใช้memmove()เพื่อย้ายส่วนสุดท้ายไปยังจุดสิ้นสุดและเปิดรูจากนั้นแทรกข้อความใหม่เข้าไปในรู หรือคุณสามารถใช้ชุดpread()/ pwrite()เพื่อทำเช่นเดียวกัน

— Zan Lynx

@EricRenouf จริงเขียนสิทธิ์ที่ไฟล์ไบนารีไม่จำเป็นต้องอัพเกรดแพคเกจที่มีมัน ในการอัพเกรดแพ็คเกจไบนารีเก่าไม่ได้ถูกเขียนไป ในความเป็นจริงมันเป็นไปไม่ได้ถ้าไบนารีกำลังทำงานอยู่ (ค้นหาETXTBSY) แต่ไบนารีเก่าจะถูกลบออกและไบนารีใหม่จะถูกเขียนลงในไฟล์ใหม่ที่มีชื่อเดียวกัน การลบไฟล์ไม่จำเป็นต้องมีสิทธิ์ในการเขียนบนพวกเขาเพียงแค่ในไดเรกทอรีที่มี (เช่น/usr/sbin/)

— marcelm

@marcelm: พูดอย่างเคร่งครัดว่าคุณไม่เพียง แต่ใช้ fseek และเขียนเท่านั้นคุณยังคงบัฟเฟอร์ส่วนที่เหลือไว้กับ RAM คุณยังสามารถบัฟเฟอร์ส่วนที่เหลือไปยังไฟล์อื่น หรือคุณสามารถเขียนเนื้อหาใหม่ไปยังไฟล์ใหม่ ไม่มีสิ่งใดที่อนุญาตให้คุณขยายไฟล์ข้อความโดยไม่มีบัฟเฟอร์ขนาดใหญ่

— slebetman

ไม่สำคัญว่าไฟล์ใน/bin(หรือไดเร็กทอรีมาตรฐานอื่น ๆ ที่เก็บไฟล์ที่เรียกทำงานได้) นั้นสามารถเขียนได้โดยรูทหรือไม่ บนเซิร์ฟเวอร์ Linux ที่ฉันใช้พวกเขาสามารถเขียนได้โดยรูท แต่ในเครื่อง OpenBSD ของฉันไม่ใช่พวกเขา

ตราบใดที่พวกเขาไม่สามารถเขียนได้โดยกลุ่มหรือ "คนอื่น"!

ไม่มีปัญหาด้านความปลอดภัยเช่น

-rwxr-xr-x 1 root root 126584 Feb 18  2016 /bin/ls

หากมีคนต้องการเขียนทับพวกเขาจะต้องเป็นรูทและหากพวกเขาเป็นrootและเขียนทับมันพวกเขาก็เป็นเช่นนั้น

การติดตั้งเวอร์ชันใหม่หรือ
เงอะงะหรือ
ผู้โจมตีมีสิทธิ์ root แล้ว

อีกสิ่งที่ควรพิจารณาคือรูทนั้นสามารถเขียนลงไฟล์ได้ไม่ว่าจะป้องกันการเขียนหรือไม่ก็ตามเพราะ ...

โปรดสังเกตด้วยว่า "สคริปต์" นั้นสามารถเรียกทำงานได้เหมือนกับไฟล์ไบนารี สคริปต์ไม่จำเป็นต้องเขียนได้ "เพราะเป็นไฟล์ข้อความ" ถ้ามีอะไรก็น่าจะได้รับอนุญาตเช่นเดียวกับไฟล์ปฏิบัติการอื่น ๆ ในไดเรกทอรีเดียวกัน

อย่าเปลี่ยนสิทธิ์ในทุกสิ่งทันที! ที่สามารถสร้างความหายนะทุกประเภทและอาจทำให้ผู้จัดการแพคเกจสับสนซึ่งอาจตรวจสอบว่าสิทธิ์ได้รับการตั้งค่าอย่างเหมาะสม นอกจากนี้ยังอาจทำให้ระบบมีความเสี่ยงหากคุณเปลี่ยนการอนุญาตโดยไม่ตั้งใจในแอปพลิเคชันที่มีความสำคัญด้านความปลอดภัย

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

จากความคิดเห็นและในการแชทมีการเรียกร้องให้มีประวัติบางอย่าง

ประวัติของการอนุญาตบนไบนารีบน Linuxไม่ใช่สิ่งที่ฉันรู้ อาจสันนิษฐานได้ว่าพวกเขาเพียงแค่สืบทอดสิทธิ์จากไดเรกทอรีหรือเพียงแค่จากค่าเริ่มต้นumaskของ Linux แต่ฉันไม่รู้จริงๆ

สิ่งที่ฉันรู้คือ OpenBSD ติดตั้งไบนารีในระบบฐาน¹ด้วยโหมดการอนุญาต 555 โดยค่าเริ่มต้น ( -r-xr-xr-x) สิ่งนี้ถูกระบุใน Makefile Fragment /usr/share/mk/bsd.own.mkที่ตั้งค่าBINMODEเป็น 555 (ยกเว้นว่ามันจะถูกตั้งค่าไว้แล้ว) นี้จะใช้ในภายหลังเมื่อการติดตั้ง executables ระหว่างในmake build/usr/src

ฉันได้ดูบันทึก CVS ที่ทำหมายเหตุประกอบไว้สำหรับไฟล์นี้และพบว่าบรรทัดนี้ในไฟล์ไม่เปลี่ยนแปลงเนื่องจากนำเข้าจาก NetBSD ในปี 1995

บน NetBSD ไฟล์จะถูกใส่เข้าไปใน CVSเป็นครั้งแรกในปี 1993 โดยBINMODEตั้งค่าเป็น 555

ดูเหมือนว่าโครงการ FreeBSD จะใช้ไฟล์เดียวกันกับ NetBSD ตั้งแต่อย่างน้อยปี 1994และหลังจากนั้นคอมมิชชันในภายหลังก็เพิ่มคำใบ้ในข้อความคอมมิชชันที่ไฟล์เก่ามาจากการเผยแพร่ซอฟต์แวร์ Berkeley รุ่น 4.4BSD

นอกเหนือจากนั้นCSRG ที่เบิร์กลีย์เก็บไว้ในแหล่งSCCSแต่พื้นที่เก็บข้อมูลของพวกเขาคืออยู่ในรูปแบบ Git บน GitHub 2ไฟล์ที่เราให้การรักษาทางนิติวิทยาศาสตร์ที่นี่ดูเหมือนจะเกิดขึ้นโดยKeith Bostic (หรือคนที่อยู่ใกล้เขา) ในปี 1990

นั่นคือเรื่องราวที่ หากคุณต้องการเหตุผลว่าทำไมฉันคิดว่าเราจะต้องถาม Keith ฉันหวังว่าจะเห็นข้อความยืนยันการเปลี่ยนแปลงที่บอกว่า " นี่ต้องเป็น 555 เพราะ ... " แต่ไม่ใช่

¹ _{ระบบ BSD มีการแบ่งส่วนที่เข้มงวดขึ้นเป็น "ระบบฐาน" และ "แพ็คเกจของบุคคลที่สาม" (พอร์ต / แพ็คเกจ) มากกว่า Linux ระบบฐานเป็นหน่วยที่เชื่อมโยงกันที่ให้สมบูรณ์ชุดของสิ่งอำนวยความสะดวกสำหรับการทำงานของระบบปฏิบัติการในขณะที่พอร์ตหรือแพคเกจถูกมองว่าเป็น "ซอฟต์แวร์ท้องถิ่น" /usr/localและได้รับการติดตั้งไว้ใต้}

² _{ที่เก็บ GitHub ที่ครอบคลุมมากขึ้นของ Unix รีลีสจาก 70 เป็นต้นไปก็มีให้เช่นกัน}

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

ขอบคุณสำหรับคำตอบ สิทธิ์ในการเขียนเป็นเรื่องปกติเนื่องจากไม่สำคัญว่าจะเป็นผู้ใช้รูท (เขาสามารถทำอะไรก็ได้) แต่มันไม่สำคัญเลยทำไมเราไม่ให้สิทธิ์ในการเขียนถ้ามันเหมือนกันตั้งแต่ต้น? มันเป็นการตัดสินใจตามอำเภอใจหรือไม่?

— t1m0th33

@ t1m0th33 ฉันเชื่อว่ามันอาจเป็นการตัดสินใจตามอำเภอใจที่ใครบางคนทำใช่ ที่ผมกล่าวว่าในระบบ OpenBSD rootฉันไฟล์ในสถานที่เหล่านั้นจะไม่สามารถเขียนได้โดย

— Kusalananda

ฉันไม่คิดว่ามันเป็นการตัดสินใจที่มีสติของทุกคน ตัวจัดการแพ็กเกจจะใช้ค่าเริ่มต้นในการติดตั้งไฟล์ด้วยบิตสิทธิ์ที่ได้รับในระหว่างกระบวนการสร้าง ขณะที่การสร้างลิงเกอร์ที่สร้างไฟล์ที่มีสิทธิ์ 755 เพราะนั่นคือสิ่งที่คุณได้รับเมื่อคุณลบ umask จาก 777 และราก umask (บนผู้จำหน่ายระบบปฏิบัติการสร้างเครื่อง) ได้ในขณะที่อาคาร 022 เพราะ 022 เป็น umask ของทุกคนและการ มันเป็น 222 สำหรับรูทจะทำงานพิเศษอย่างไม่มีจุดหมาย

— Henning Makholm

+1 สำหรับ "อย่าเปลี่ยนการอนุญาตในทุกสิ่งตอนนี้!" ผมเห็นคำถามมากมายเช่นว่าเมื่อถามอูบุนตูที่ผู้ใช้ไม่ได้chmod -R บน/usrหรือ/varและประหลาดใจ - พวกเขาsudoไม่ทำงานหรือสิ่งอื่นที่ไม่ได้ทำงาน

— Sergiy Kolodyazhnyy

ในอดีตไม่มีการอนุญาตให้เขียนสำหรับรูทจะไม่มีผลกระทบ (รูทสามารถ chmod อะไรและไม่จำเป็นต้องเพราะรากไม่เคยได้รับ EPERM เมื่อเปิดหรือเขียนอยู่แล้ว) ฉันสงสัยว่าสิ่งที่ 555 เริ่มต้นขึ้นหรือไม่เพราะรูทนั้นถูก จำกัด หรือไม่ (เมื่อ securelevels ปรากฏขึ้นครั้งแรกในช่วงเวลาเดียวกันกับ 4.4BSD หรือต้น 386BSD / NetBSD ต้น)