internals of sudo ทำงานอย่างไร

วิธีการที่ไม่sudoทำงานภายใน? วิธีการที่จะเป็นไปได้ว่ามันจะกลายเป็นรากโดยไม่ต้องมีรหัสผ่านรากแตกต่างsu? อะไร syscalls ฯลฯ มีส่วนร่วมในกระบวนการ? ไม่ใช่ช่องโหว่ความปลอดภัยที่อ้าปากค้างใน Linux (เช่นทำไมฉันจึงไม่สามารถคอมไพล์โปรแกรมปะแก้sudoที่ทำตามปกติsudoไม่ได้ แต่ไม่ได้ขอรหัสผ่านของผู้ใช้ที่ไม่ได้รับสิทธิพิเศษ)?

ฉันได้อ่านเข้าสู่ระบบและ internals ฉันได้อ่านด้วยsudo ตั้งใจจะใช้อย่างไร แต่แม้จะมีชื่อที่พวกเขาส่วนใหญ่จัดการกับความแตกต่างระหว่างและsusudo

หากคุณดูที่ปฏิบัติการได้sudo:

$ which sudo
/usr/bin/sudo
$ ls -la /usr/bin/sudo
---s--x--x 2 root root 208808 Jun  3  2011 /usr/bin/sudo

---s--x--xคุณจะพบว่าจะดำเนินการบิตได้รับอนุญาต สิ่งเหล่านี้สามารถแบ่งย่อยได้ดังนี้:

-|--s|--x|--x
-      - first dash denotes if a directory or a file ("d" = dir, "-" = file)  
--s    - only the setuid bit is enabled for user who owns file
--x    - only the group execute bit is enabled
--x    - only the other execute bit is enabled

ดังนั้นเมื่อโปรแกรมมีการเปิดใช้งานบิต setuid (เรียกอีกอย่างว่า SUID) หมายความว่าเมื่อมีคนเรียกใช้โปรแกรมนี้มันจะทำงานด้วยข้อมูลประจำตัวของผู้ใช้ที่เป็นเจ้าของไฟล์หรือที่รู้จัก รูทในกรณีนี้

ตัวอย่าง

ถ้าฉันใช้คำสั่งต่อไปนี้เป็นผู้ใช้ saml:

$ whoami
saml

$ sudo su -
[sudo] password for saml: 

คุณจะสังเกตเห็นว่าการดำเนินการของsudoจริงรันเป็นรูท:

$ ps -eaf|grep sudo
root     20399  2353  0 05:07 pts/13   00:00:00 sudo su -

กลไก setuid

ถ้าคุณอยากรู้วิธีการทำงานของ SUID man setuidดูที่ นี่คือข้อความที่ตัดตอนมาจากหน้าคนที่อธิบายได้ดีกว่าที่ฉันสามารถทำได้:

setuid () กำหนด ID ผู้ใช้ที่มีประสิทธิภาพของกระบวนการเรียก หาก UID ที่มีประสิทธิภาพของผู้โทรเป็นรูท UID จริงและ set-user-ID ที่บันทึกไว้จะถูกตั้งค่าด้วย ภายใต้ Linux, setuid () ถูกนำไปใช้เช่นเวอร์ชัน POSIX ที่มีคุณสมบัติ _POSIX_SAVED_IDS สิ่งนี้อนุญาตให้โปรแกรม set-user-ID (นอกเหนือจากรูท) โปรแกรมเพื่อปล่อยสิทธิผู้ใช้ทั้งหมดทำงานที่ไม่ได้รับสิทธิพิเศษจากนั้นเปิดใช้งาน ID ผู้ใช้เดิมที่มีประสิทธิภาพในลักษณะที่ปลอดภัย

หากผู้ใช้เป็นรูทหรือโปรแกรมเป็น set-user-ID-root ต้องระมัดระวังเป็นพิเศษ setuid () ฟังก์ชั่นการตรวจสอบ ID ผู้ใช้ที่มีประสิทธิภาพของผู้โทรและถ้ามันเป็น superuser ID ผู้ใช้ที่เกี่ยวข้องกับกระบวนการทั้งหมดจะถูกตั้งค่าเป็น uid หลังจากสิ่งนี้เกิดขึ้นเป็นไปไม่ได้ที่โปรแกรมจะได้รับสิทธิ์พิเศษระดับรูต

แนวคิดหลักที่นี่คือโปรแกรมมีรหัสผู้ใช้จริง (UID) และมีประสิทธิภาพ (EUID) Setuid กำลังตั้งค่า userid ที่มีประสิทธิภาพ (EUID) เมื่อเปิดใช้งานบิตนี้

จากมุมมองของเคอร์เนลเป็นที่ทราบกันว่าในตัวอย่างของเราsamlยังคงเป็นเจ้าของดั้งเดิม (UID) แต่ EUID ถูกตั้งค่าโดยผู้ใดก็ตามที่เป็นเจ้าของไฟล์ปฏิบัติการ

setgid

ฉันควรพูดถึงว่าเมื่อเราทำลายการอนุญาตในคำสั่ง sudo กลุ่มบิตที่สองนั้นสำหรับการอนุญาตกลุ่ม บิตกลุ่มยังมีบางสิ่งที่คล้ายกับ setuid เรียกว่า set group id (aka. setgid, SGID) สิ่งนี้ทำเช่นเดียวกับ SUID ยกเว้นจะดำเนินการตามกระบวนการด้วยข้อมูลรับรองกลุ่มแทนข้อมูลรับรองเจ้าของ

อ้างอิง

• หน้า setuid วิกิพีเดีย
• setuid man page

sudoไบนารีที่แท้จริงคือรูทของ setuidและคุณจะไม่สามารถแปลงไฟล์เป็นสิ่งมีชีวิตที่ตั้งค่าไว้ด้วยวิธีนี้

setuid และ setgid (ย่อมาจาก "set user ID เมื่อเรียกใช้งาน" และ "set group ID เมื่อดำเนินการ" ตามลำดับ) [1] คือแฟล็กสิทธิ์การเข้าถึง Unix ที่อนุญาตให้ผู้ใช้เรียกใช้งานได้ด้วยสิทธิ์ของเจ้าของหรือกลุ่มปฏิบัติการตามลำดับ เพื่อเปลี่ยนพฤติกรรมในไดเรกทอรี

เพื่อตอบคำถามเกี่ยวกับ syscalls ที่ดูเหมือนว่าไม่มีใครแตะต้อง syscalls สำคัญอย่างใดอย่างหนึ่งคือ setresuid () หรือ setresgid () ฉันแน่ใจว่ามีคนอื่น ๆ แต่ 2 คนนี้ดูเหมือนจะค่อนข้างเฉพาะกับ setuid / sudo