เป็นการดีที่จะเรียกใช้ daemon ภายใต้บัญชีผู้ใช้ที่ไม่ใช่รูทหรือไม่?


13

ฉันได้พัฒนาแอปพลิเคชันที่ใช้ NTP เพื่อเปลี่ยนเวลาเครือข่ายเพื่อซิงค์คอมพิวเตอร์สองเครื่องของฉัน มันทำงานเป็นrootเพราะหลังเท่านั้นที่ได้รับอนุญาตให้เปลี่ยนเวลาและวันที่บน Linux (ฉันเดา)

ตอนนี้ฉันต้องการเรียกใช้ในฐานะผู้ใช้ แต่ฉันต้องเข้าถึงเวลา

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

โดยปกติแล้ว NTP daemon ควรจะทำงานเป็นntpบัญชีผู้ใช้ (อย่างน้อยในระบบ Linux) ดังนั้นคุณไม่จำเป็นต้องทำการเปลี่ยนแปลงนี้ คุณติดตั้งแพคเกจ NTP ใดบ้าง

6
การเรียกใช้ daemon ภายใต้บัญชีที่ไม่ใช่รูทนั้นเรียกว่า "สิทธิ์การรูทรูท" และเป็นวิธีปฏิบัติที่ดีที่รู้จักกันทั่วไปเนื่องจากจะจำกัดความเสียหายที่อาจเกิดขึ้นจากช่องโหว่ความปลอดภัยใน daemon

1
ดูวิกิพีเดียสำหรับ " การแยกสิทธิพิเศษ "
Kusalananda

ฉันรวบรวม NTP จากแหล่งข้อมูล ฉันไม่มีกลุ่ม NTP
ไม่ระบุชื่อ

@xhaltar คุณสามารถสร้างกลุ่ม NTP และผู้ใช้ ในการกำหนดวิธีการเริ่มบริการ (ผู้ใช้กลุ่ม ฯลฯ ) คุณสามารถสร้าง / แก้ไขสคริปต์เริ่มต้นบริการสร้าง / กำหนดค่าหน่วย systemd
Pl4nk

คำตอบ:


15

เป็นการดีที่จะเรียกใช้ daemon ภายใต้บัญชีผู้ใช้ที่ไม่ใช่รูทหรือไม่?

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

ฉันจะให้ "ความสามารถ" เช่น "CAP_SYS_TIME" หรือไม่

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

ฉันจะใช้วิธีอื่นในการทำเช่นนั้นซึ่งจะได้รับการพิจารณาว่าเป็น "การปฏิบัติที่ดี" หรือไม่?

คุณสามารถเพิ่มความปลอดภัยตัวอย่างเช่น:

  • เรียกใช้บริการในฐานะผู้ใช้ที่ไม่มีสิทธิ์โดยไม่มีเชลล์
  • ใช้chrootเพื่อล็อคผู้ใช้ในไดเรกทอรีบ้าน

หมายเหตุ: Chroot ไม่ให้ความปลอดภัยหากคุณเป็นรูทและทำงานบน Linux ผู้ใช้รูทสามารถสร้างไดเร็กตอรี่ใน chroot, เปิดไดเร็กตอรี่ root ของ chroot, chroot ไปที่ไดเร็กตอรี่ใหม่, chdir กลับไปสู่รูทจริง, จากนั้น chroot ไปยังรูทจริง. BSD แก้ไขปัญหานี้โดยไม่อนุญาตให้นำไดเรกทอรี fd ไปไว้ใน chroot
Kevin

@ เควินหากคุณรูทคุณยังสามารถทำกระบวนการ ptrace นอก chroot และมีวิธีอื่น ๆ อีกมากมายที่จะหลีกเลี่ยงมัน chroot เพียงอย่างเดียวไม่สามารถหยั่งรากได้
Gilles 'ดังนั้น - หยุดความชั่วร้าย'

//, emp.jar.stสร้างผู้ใช้ด้วยตัวเองด้วยเหตุผลด้านความปลอดภัย การปฏิบัติที่ดีมาก
นาธาน Basanese

รอถ้าฉันเป็นผู้ใช้ฉันสามารถล็อคผู้ใช้ลงในไดเรกทอรีเฉพาะได้หรือไม่ เช่น "/ opt" (เช่น)
Anonymous12223

@xhaltar เพื่อล็อคกระบวนการที่ดำเนินการโดยUSERในไดเรกทอรีคุณใช้chroot(เรียกใช้ในฐานะผู้ใช้รูท) อย่างไรก็ตามคุณต้องสร้างและเริ่มต้นคุก (ไดเรกทอรี) ก่อน chroot <path/to/jail> <command>ในระยะสั้นคุณต้องวางห้องสมุดและไบนารีความต้องการของกระบวนการของคุณลงในคุกนี้โทรแล้ว บทแนะนำที่ดีพร้อมตัวอย่างที่คุณต้องการมีให้ที่นี่
Pl4nk

13
  • ฉันจะใช้วิธีอื่นในการทำเช่นนั้นซึ่งจะได้รับการพิจารณาว่าเป็น "การปฏิบัติที่ดี" หรือไม่?

นอกจากว่าคุณมีเหตุผลที่แข็งแกร่งและไม่อาจปฏิเสธได้คุณควรใช้แพ็คเกจ NTP ที่มาพร้อมกับการแจกจ่าย GNU / Linux ของคุณ NTP daemon มาตรฐานใช้เวลาหลายปีในการพัฒนาและมาพร้อมกับคุณสมบัติที่ซับซ้อนเช่นการชะลอหรือเร่งความเร็วนาฬิการะบบของคุณเพื่อซิงค์กับเครือข่ายหรือนาฬิกา GPS มันได้รับการปรับให้เหมาะกับนาฬิกาซิงค์ดังนั้นจึงน่าจะเป็นเครื่องมือที่ดีที่สุดสำหรับวัตถุประสงค์นั้น

ntpdยังคงได้รับการดูแลพิจารณาจากการอัปเดตล่าสุด (เมื่อเขียนโพสต์นี้) หากคุณต้องการคุณสมบัติเพิ่มเติมฉันขอแนะนำให้คุณติดต่อผู้พัฒนาโดยตรงเชื่อในสิ่งที่พวกเขาพูดเกี่ยวกับสิ่งนั้น


5

หากคุณมีโปรแกรมที่ต้องสามารถใช้งานฟังก์ชันX (เช่นปรับแต่งนาฬิกา) และคุณสามารถให้สิทธิ์ / พลังงานในการทำหน้าที่Xและไม่มีอะไรอื่นเลยมันดีกว่าให้ตัวอักษรทั้งหมด ซุป. นี้เป็นที่รู้จักกันเป็นหลักการของสิทธิน้อย พิจารณาว่าจะเกิดอะไรขึ้นถ้าโปรแกรมของคุณมีข้อผิดพลาดไม่ว่าจะเป็นข้อผิดพลาดในการเขียนโปรแกรมทั่วไปหรือช่องโหว่ความปลอดภัยที่เอาเปรียบ ถ้ามันทำงานเป็น "รูท" มันสามารถลบไฟล์ของทุกคน - หรือส่งออกไปยังผู้โจมตี หากสิ่งเดียวที่โปรแกรมสามารถทำได้คือจัดการกับนาฬิกา (และฟังก์ชั่นที่ไม่ได้รับสิทธิพิเศษเช่นการจัดการไฟล์ในไดเรกทอรีที่ถูกล็อค) นั่นคือสิ่งที่แย่ที่สุดที่สามารถเกิดขึ้นได้หากโปรแกรมนั้นโกง

โดยการใช้ไซต์ของเรา หมายความว่าคุณได้อ่านและทำความเข้าใจนโยบายคุกกี้และนโยบายความเป็นส่วนตัวของเราแล้ว
Licensed under cc by-sa 3.0 with attribution required.