เหตุใดจึงแนะนำให้สร้างกลุ่มและผู้ใช้สำหรับบางแอปพลิเคชัน

เวลาส่วนใหญ่เมื่อติดตั้งโปรแกรมจากแหล่งที่มาขอแนะนำให้สร้างผู้ใช้ใหม่และกลุ่มใหม่และให้/usr/local/<myapp>ความเป็นเจ้าของผู้ใช้และกลุ่มที่เพิ่งสร้างขึ้น

• ทำไมการฝึกฝนเช่นนี้จึงถือเป็นแนวปฏิบัติที่ดี?

• มันปรับปรุงอะไร

ตัวอย่าง: ผู้ใช้ mysql / กลุ่ม mysql สำหรับเซิร์ฟเวอร์ฐานข้อมูล MySQL

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

daemon รันในฐานะผู้ใช้เฉพาะเพื่อที่ว่าหากมันทำงานผิดปกติ (เนื่องจากข้อผิดพลาดอาจถูกทริกเกอร์โดยผู้โจมตี) ความเสียหายที่สามารถทำได้นั้นมี จำกัด : เฉพาะไฟล์ข้อมูลของ daemon เท่านั้นที่ได้รับผลกระทบ ซึ่งสามารถเกิดขึ้นได้) ยกตัวอย่างเช่นฐานข้อมูลภูตmysqldวิ่งเป็นผู้ใช้เฉพาะกลุ่มmysql:mysqlและไฟล์ข้อมูลของฐานข้อมูล ( /var/lib/mysql/*) mysql:mysqlเป็นของ

โปรดทราบว่า daemon ที่สามารถเรียกใช้งานได้และข้อมูลสแตติกและไฟล์การกำหนดค่าอื่น ๆ ที่ใช้ แต่ไม่ควรแก้ไขโดย daemon ต้องไม่เป็นของผู้ใช้เฉพาะ ควรเป็นเจ้าของroot:rootเช่นไฟล์โปรแกรมและการกำหนดค่าส่วนใหญ่ mysqldกระบวนการไม่มีการเขียนทับธุรกิจ/usr/sbin/mysqldหรือ/etc/mysql/my.cnfเพื่อให้ไฟล์เหล่านี้จะต้องไม่เป็นของmysqlผู้ใช้หรือสามารถเขียนได้โดยmysqlผู้ใช้หรือmysqlกลุ่ม หากไฟล์บางไฟล์จำเป็นต้องอ่านได้โดย daemon และผู้ดูแลระบบเท่านั้นพวกเขาควรเป็นเจ้าของโดยผู้ใช้รูทและกลุ่มเฉพาะและมีโหมด 0640 ( rw-r-----)

ประเภทพิเศษของ executables ที่ไม่สามารถเป็นเจ้าของได้root:rootคือโปรแกรมที่เรียกใช้โดยผู้ใช้ แต่จำเป็นต้องเรียกใช้ด้วยสิทธิ์พิเศษ executables เหล่านี้จะต้องsetuidรูทหากจำเป็นต้องรัน (อย่างน้อยก็ในบางส่วน) ในฐานะรูท จากนั้นไฟล์ที่เรียกทำงานจะต้องมีโหมด 4755 ( rwsr-xr-x) หากโปรแกรมต้องการสิทธิ์พิเศษ แต่ไม่เป็นรูทดังนั้นโปรแกรมควรทำการ setgid เพื่อให้สิทธิ์พิเศษมาถึงกลุ่มและไม่ใช่ผู้ใช้ ปฏิบัติการได้แล้วมีโหมด 2755 ( rwxr-sr-x) เหตุผลคือสองเท่า:

• ปฏิบัติการไม่ควรได้รับอนุญาตให้แก้ไขตัวเองดังนั้นหากผู้ใช้จัดการเพื่อหาช่องโหว่พวกเขาอาจจะสามารถแก้ไขไฟล์ข้อมูลที่ใช้โดยโปรแกรม แต่ไม่ฉีดม้าโทรจันเข้าสู่ปฏิบัติการเพื่อโจมตีผู้ใช้อื่นที่รันโปรแกรม .
• ไฟล์ข้อมูลของไฟล์เรียกทำงานอยู่ในกลุ่ม โปรแกรม setuid จะต้องสลับไปมาระหว่างผู้ใช้จริง (ผู้ใช้ที่เรียกใช้โปรแกรม) เพื่อโต้ตอบกับผู้ใช้และผู้ใช้ที่มีประสิทธิภาพ (ผู้ใช้ที่โปรแกรมกำลังทำงาน) เพื่อเข้าถึงไฟล์ข้อมูลส่วนตัว (เหตุผลสำหรับมัน เพื่อรับสิทธิพิเศษ) โปรแกรม setgid สามารถแยกข้อมูลต่อผู้ใช้ที่เข้าถึงกลุ่มได้เท่านั้น (เช่นโดยการจัดเก็บไฟล์ที่ผู้ใช้เป็นเจ้าของในไดเรกทอรีที่เข้าถึงได้เฉพาะกับ root และกลุ่มของโปรแกรม)

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

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

ในฐานะที่เป็นตัวอย่างmysql/ mysqlเป็นเจ้าของที่เก็บข้อมูลสำหรับไฟล์ฐานข้อมูล mysql ป้องกันไม่ให้ใครก็ตามที่ไม่ได้ใช้ API ของแอปพลิเคชันจากการทำลายฐานข้อมูล นอกจากนี้ผู้ใช้mysqlมักจะไม่มีกระสุนจริงดังนั้นไม่มีใครสามารถเข้าสู่ระบบในฐานะผู้ใช้รายนั้นได้

การสร้างกลุ่ม / ผู้ใช้ใหม่สำหรับ daemon ที่ติดตั้งใหม่ช่วยเพิ่มความปลอดภัย เมื่อกระบวนการเซิร์ฟเวอร์ทำงานภายใต้ผู้ใช้ดังกล่าวจะถูก จำกัด สิทธิ์การเข้าถึงของผู้ใช้นั้น ในการเปรียบเทียบ: เมื่อมันถูกเรียกใช้ในฐานะรูทมันสามารถทำทุกอย่างได้

ความแตกต่างนี้มีความสำคัญในกรณีที่ daemon ของคุณตั้งค่าผิดพลาดและ / หรือมีข้อผิดพลาดเกี่ยวกับความปลอดภัย

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

การเรียกใช้ daemon ภายใต้ผู้ใช้พิเศษของตัวเองเป็นเพียงเทคนิคความปลอดภัยเพียงอย่างเดียวส่วนอื่น ๆ รวมถึง 'chrooting' หรือใช้ระบบควบคุมการเข้าถึง (MAC) (เช่น SELinux)

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

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

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

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

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