ฉันคิดว่าอาจเป็นประโยชน์ที่จะมีผู้ใช้ที่มีสิทธิ์สูงกว่าผู้ใช้รูท

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

อย่างไรก็ตามฉันต้องการความสามารถในการปฏิเสธสิทธิ์ในการรูทกรณีที่แยกได้เป็นกรณี ๆ ไป

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

เนื่องจากการอัปเดต apt-get นั้นดำเนินการโดยรูทหรือด้วยสิทธิ์ sudo apt-get จึงมีความสามารถในการแทนที่ไฟล์ที่ไม่ต้องการในระหว่างการอัพเดต

หากฉันสามารถปฏิเสธสิทธิพิเศษเหล่านี้ให้กับไฟล์เหล่านี้ได้ฉันสามารถกำหนดให้เป็นลิงค์ไปยัง/dev/nullหรืออาจมีไฟล์ตัวยึดตำแหน่งว่างที่อาจมีสิทธิ์ที่จะปฏิเสธไม่ให้แทนที่ไฟล์ในระหว่างการอัปเดต

นอกจากนี้ฉันไม่สามารถช่วยได้ แต่ได้รับการเตือนเกี่ยวกับบรรทัดที่ถูกกล่าวในการสัมภาษณ์กับหนึ่งในผู้สร้างอูบุนตูเมื่อชายคนนั้นพูดบางอย่างเกี่ยวกับวิธีที่ผู้ใช้เชื่อถือ "us" (อ้างอิงจาก Ubuntu devs) "เพราะเรามีราก "ซึ่งเป็นการอ้างอิงถึงวิธีการอัปเดตระบบด้วยการอนุญาตรูท

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

ฉันเพิ่งคิดเกี่ยวกับเรื่องนี้และไม่ได้ใช้เวลาในความคิดจนถึงตอนนี้และฉันค่อนข้างมั่นใจว่าจะสามารถหาคำตอบได้ อย่างไรก็ตามฉันอยากรู้ว่าสิ่งนี้ได้ทำไปแล้วหรือว่านี่อาจไม่ใช่แนวคิดหรือแนวคิดใหม่

โดยทั่วไปดูเหมือนว่าควรมีวิธีที่จะมีผู้ใช้ super super ซึ่งจะได้รับอนุญาตนอกเหนือจากระบบโดยเพียงหนึ่งองศา

หมายเหตุ: แม้ว่าฉันรู้สึกว่าคำตอบที่ยอมรับนั้นตรงกับเกณฑ์มากที่สุด แต่ฉันชอบคำตอบของ @CR ด้วย

ฉันต้องการสร้างผู้ใช้จริงบนต้นไม้ (ฉัน) แต่ฉันเดาว่าฉันจะต้องนั่งลงวันหนึ่งเมื่อฉันมีเวลาคิดออก

นอกจากนี้ฉันไม่ได้พยายามเลือกบน Ubuntu ที่นี่ ฉันจะไม่ใช้มันเป็น distro หลักของฉันถ้าฉันรู้สึกเชิงลบเกี่ยวกับเรื่องนี้

"ผู้ใช้" ที่คุณต้องการเรียกว่าโมดูลความปลอดภัยของ LSM: Linux รู้จักมากที่สุดคือ SELinux และ AppArmor

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

คุณเข้าใจผิดแนวคิดของrootผู้ใช้

ในภาษาอังกฤษธรรมดาrootอยู่ที่ "ด้านบนของต้นไม้"

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

โซลูชันที่ให้ที่นี่ - รวมถึง AppArmor และ SELinux - อย่าเปลี่ยนแปลงสิ่งนี้จริงๆ พวกเขาเพียงแค่อนุญาตให้ควบคุมธัญพืชrootและกระบวนการอย่างละเอียดยิ่งขึ้น

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

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

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

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

chattr +i <file>

แม้แต่รูทจะสามารถทำสิ่งใด ๆ กับพวกเขาได้ยกเว้นว่าจะลบสถานะออกไป นอกจากนี้ยังเป็นไปได้ที่จะใช้ระบบ container / namespace เพื่อป้องกันการเข้าถึงรูท แต่ดูเหมือนว่า overkill สำหรับสิ่งที่คุณต้องการ

• แทนที่จะมีผู้ใช้ระดับสูงพิเศษคุณสามารถ จำกัด การรูทได้ ดู อะไรคือวิธีที่แตกต่างในการตั้งค่าการอนุญาตไฟล์ ฯลฯ ใน gnu / linux

• นอกจากนี้ยังมี AppArmor และ SELinux

• และ / หรือกำหนดค่าsudoเพื่อที่คุณจะไม่ให้สิทธิ์แบบเต็มแก่ผู้ใช้ คุณสามารถตั้งค่าเพื่อให้ผู้ใช้สามารถเรียกใช้คำสั่งที่ตกลงไว้ล่วงหน้าเท่านั้นโดยมีอาร์กิวเมนต์ที่ตกลงล่วงหน้า

• คุณยังสามารถใช้การจำลองเสมือนเพื่อ จำกัด การรูท:

  • cgroups, namespaces, chroot ฯลฯ (นักเทียบท่าทำสิ่งนี้)
  • Xen
  • Virtualbox

• ดูเพิ่มเติมที่etckeeper: การแก้ไขเครื่องมือนี้จะควบคุม/etcไดเรกทอรีและซิงโครไนซ์กับ apt ตามค่าเริ่มต้นจะไม่ปลอดภัยการติดตั้งที่เป็นอันตรายอาจก่อวินาศกรรมได้ แต่คุณสามารถทำให้มันผลักดันการเปลี่ยนแปลงไปยังแหล่งเก็บข้อมูลสำรองที่มีไฟ

• การใช้การควบคุมการแก้ไขโดยทั่วไปพร้อมที่เก็บข้อมูลสำรองที่มีไฟ ช่วยด้วยความเสียหายโดยไม่ตั้งใจตั้งใจและความล้มเหลวของฮาร์ดแวร์

ที่เก็บข้อมูลสำรองแบบไฟร์วอลล์อาจอยู่บนเครื่องอื่นบนอินเทอร์เน็ตหรือเครื่องเสมือนอื่น (หรือโฮสต์ของเครื่องเสมือน)

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

ขึ้นอยู่กับว่าคุณจะวางข้อ จำกัด มากน้อยเพียงใดสคริปต์การติดตั้งอาจถูกคาดหวังให้หยุดการทำงาน

สำหรับวิธี จำกัด แอปพลิเคชันและผู้ใช้คุณสามารถเขียนนโยบาย AppArmor หรือนโยบาย SELinux นโยบายดังกล่าวซึ่งจะได้รับการสนับสนุนมากขึ้นนั้นขึ้นอยู่กับการกระจายของคุณ: Debian based มีการรองรับ AppArmor ที่ดีขึ้นในขณะที่การแจกจ่ายแบบอิง Fedora / RHEL เปิดใช้งาน SELinux ตามค่าเริ่มต้น

ทั้ง AppArmor และ SELinux ทำงานกับนโยบายบัญชีขาวซึ่งมีกฎที่อนุญาต (หรือปฏิเสธ) การกระทำที่เฉพาะเจาะจง นโยบายจะถูกนำไปใช้กับกระบวนการที่ผู้บริหารในทำนองเดียวกันผู้ใช้สามารถถูก จำกัด เมื่อนโยบายถูกนำไปใช้กับกระบวนการของพวกเขาเมื่อเข้าสู่ระบบ นโยบายความคิดที่ดีไม่สามารถหลีกเลี่ยงได้ (หากไม่พิจารณาข้อบกพร่องเคอร์เนล) กระบวนการที่ จำกัด ซึ่งทำงานในฐานะรูท (uid 0) ถูก จำกัด โดยนโยบายที่ตั้งค่าไว้และไม่สามารถเปลี่ยนแปลงได้เว้นแต่จะได้รับอนุญาตอย่างชัดเจนในนโยบาย

นโยบายภาษา AppArmor กำหนดกฎการปฏิเสธซึ่งสามารถนำมาใช้ในการสร้างนโยบายบัญชีดำ เป็นสถานที่ที่ดีที่จะเริ่มต้นด้วยการเป็น AppArmor AppArmor หน้าคน , วิกิพีเดีย/etc/apparmor.d/และกำลังมองหาการกำหนดค่าที่มีอยู่ในการกระจายของคุณใน

มากมาย SELinux การบริหารและการพัฒนาวัสดุที่มีอยู่ในSELinux วิกิพีเดีย นโยบายการอ้างอิงของ SELinux นั้นโฮสต์บน github

ฉันไม่อยากเชื่อเลยว่าจะไม่มีใครพูดถึงการปักหมุด ...

สองสามปีที่ผ่านมาไมโครซอฟท์เปิดตัวแพทช์ที่ทำลายเครื่อง Windows 10 จากการพูดคุยกับ Samba NT4 Domain Controllers เก่าของเรา เมื่อพบปัญหาเราตรึงแพ็คเกจ Samba เพื่อให้อยู่ในเวอร์ชันปัจจุบันและaptยังทำงานได้อย่างถูกต้อง

Debian Walkthroughเต็มอธิบายถึงกระบวนการได้ดี:

ใน/etc/apt/preferences(หรือภายใต้แฟ้มใหม่/etc/apt/preferences.d/), เพิ่มข้อความบางส่วนระบุว่าแพคเกจและรุ่น:

Package: samba
Pin: release v=3.6.6-6+deb7u7
Pin-Priority: 900

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

หมายเหตุ: คำตอบนี้สมมติว่าคุณมีปัญหา XY

จริงๆแล้วมันค่อนข้างง่าย

รูทคือ "ผู้ใช้ super super" ของคุณ

สร้างบัญชีที่เรียกว่า "ผู้ดูแลระบบ" และให้สิทธิ์การใช้งานรูททั้งหมดแก่เขายกเว้นบัญชีที่คุณไม่ต้องการ

จากนั้นสร้างผู้ใช้ชื่อ bob และให้เขาเป็นผู้ดูแลระบบ โดยใช้ su หรือแม้แต่ sudo

ตอนนี้คุณมีผู้ใช้ปกติ (bob) ผู้ใช้ระดับสูงที่สามารถทำสิ่งต่าง ๆ ของผู้ดูแลระบบ (ผู้ดูแลระบบ) และผู้ใช้ระดับสูงพิเศษ (รูท)

หากคุณต้องการเปลี่ยนชื่อ "รูท" เป็นอย่างอื่นคุณสามารถทำได้ ในทางเทคนิคเฉพาะ id ผู้ใช้ (0) มีความสำคัญ

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

คำถามจริงที่คุณต้องการถามคือ:

มีวิธีป้องกัน APT จากการติดตั้งไฟล์เฉพาะหรือไม่?

นั่นคือสิ่งที่แตกต่างอย่างสิ้นเชิงจากสิ่งที่คุณถามในหลายระดับ

ตอนนี้สำหรับคำถามนั้นฉันไม่แน่ใจ 100% แต่ฉันรู้ว่าตัวจัดการแพ็กเกจอื่น ๆ มีตัวเลือกในการป้องกันการติดตั้งไฟล์เฉพาะ (ตัวอย่างเช่นระบบ Portage ของ Gentoo มีตัวเลือกINSTALL_MASK=ซึ่งยอมรับเชลล์จริงๆ รูปแบบการจับคู่สไตล์ของสิ่งที่ไม่ได้ติดตั้ง) ฉันยินดีมากกว่าที่จะเดิมพันว่ามีตัวเลือกดังกล่าวสำหรับ APT (หรืออาจเป็น dpkg เอง)

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

ทำงานจากไดรฟ์ที่ติดตั้ง

โปรดทราบว่านี่เป็นคำตอบเชิงแนวคิดส่วนใหญ่ แต่ฉันคิดว่ามันควรจะทำงานและมีจิตวิญญาณกับสิ่งที่คุณต้องการบรรลุ

ให้ system X เป็นระบบการทำงานของคุณและ system Y เป็นระบบอื่นที่คุณควบคุม

1. เมานต์ไดเร็กทอรีจาก Y เป็นไดรฟ์ใน X
2. ตั้งค่าสิทธิ์ในลักษณะที่ผู้ใช้รูท X มีสิทธิ์ในทุกสิ่งในไดรฟ์ที่ติดตั้งนี้โดยมีข้อยกเว้นเล็กน้อย

ตอนนี้คุณมี 'รากการทำงาน' ซึ่งสามารถทำเกือบทุกอย่างและคุณมี 'รากสุดยอด' ของคุณซึ่งเป็นบัญชีรูทจริงของระบบ Y ซึ่งสามารถทำทุกอย่างได้อย่างแท้จริง

คุณสามารถเรียกใช้ไฮเปอร์ไวเซอร์ชนิดที่ 1 เช่นXen hypervisor และมีการโฮสต์ระบบปฏิบัติการปกติของคุณในฐานะแขกเสมือนจริง ไฮเปอร์ไวเซอร์ควบคุมเสมือนเกสต์ OS ที่ระดับ "ลึก" กว่ารูทเนื่องจากมีการควบคุมฮาร์ดแวร์ (เสมือน) ที่เกสต์เรียกใช้

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

ความรู้สึกของฉันว่าวิธีนี้อาจจะเกินความจริง

ลองดูที่cgroupsและnamespaces ลินุกซ์เป็นวิธีทางเลือกของการบรรลุเป้าหมายประเภทนี้เช่นเดียวกับเครื่องมือขึ้นอยู่กับพวกเขาเช่นหางและLXD

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

ถอนการติดตั้ง sudo

วิธีการถอนการติดตั้งsudoและ symlink /bin/suไป/bin/false? เชื่อมโยงกับการทำให้แน่ใจว่าrootไม่สามารถเข้าสู่ระบบผ่านsshและคุณได้ล็อคระบบ

นั่นทำให้rootผู้ใช้ Super * Super และคนอื่น ๆ ด้อยกว่า

สำหรับไฟล์ที่ถูกแทนที่ระหว่างการอัพเดตอย่าเพิ่งทำการอัพเดทใด ๆ เปลี่ยนสิทธิ์ของไฟล์เป็น440หรือ444ไม่สามารถเขียนได้ หรือใส่ไว้ในที่เก็บคอมไพล์ดังนั้นหากพวกมันถูกเขียนทับมันสามารถเปลี่ยนกลับได้