ฉันจะอนุญาตให้ผู้ใช้ที่ไม่ใช่รูทควบคุมเซอร์วิส systemd ด้วยอินสแตนซ์ได้อย่างไร


12

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

%dba = /usr/bin/systemctl start database@awsesomeapp
%dba = /usr/bin/systemctl start database@anotherawsesomeapp
%dba = /usr/bin/systemctl start database@yetanotherawsesomeapp
%dba = /usr/bin/systemctl start database@wowyetanotherawsesomeapp
# ... other "verbs" omitted for brevity

ที่ไม่ครอบคลุมอินสแตนซ์ที่อาจมีอยู่ในอนาคตและ dba จะไม่สามารถทำได้

$ sudo systemctl start database@omgwowyetanotherawsesomeapp

อย่างไรก็ตามฉันคิดในแง่ของบรรจุภัณฑ์มากกว่าที่คิดกับระบบเฉพาะ

โปรดทราบว่าดังที่แสดงในคำตอบที่น่าอัศจรรย์สำหรับคำถามอื่นที่เกี่ยวข้องการใช้ sudo globs สำหรับสิ่งนี้ไม่ปลอดภัยในท้ายที่สุด:

%dba ALL = /usr/bin/systemctl start database@[a-z]* # UNSAFE!

อนุญาต

$ sudo systemctl start database@awsesomeapp unrelatedservice

ฉันสงสัยว่าใช้sudoจะไม่แก้ปัญหาของฉัน (แม้ว่าฉันหวังว่าฉันผิด) มีวิธีอื่นใดที่อนุญาตให้ผู้ใช้ที่ไม่ใช่รูทควบคุมsystemdบริการหรือไม่?

สำหรับสิ่งที่คุ้มค่าฉันต้องทำสิ่งนี้ในระบบ CentOS 7 และระบบ RHEL7 ในอนาคต ฉันจะสนใจโซลูชันที่ทำงานกับ Arch Linux ด้วย

คำตอบ:


1

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

สร้างสคริปต์ที่รันในฐานะรูทและรันสิ่งนี้:

/usr/bin/systemctl start database@

ทำให้สคริปต์รับข้อโต้แย้งเช่นแอพที่น่ากลัวดังนั้นจึงเรียกใช้งานสิ่งนี้:

สคริปต์ดำเนินการ: / usr / bin / systemctl start database @ anotherawsesomeapp

ให้สิทธิ์ผู้ใช้แก่คุณในการเรียกใช้ไฟล์ script.sh ด้วย / etc / sudoers

scriptuser ALL=(ALL) NOPASSWD: /path/to/script.sh

ผู้ใช้สามารถเรียกใช้เช่นนี้:

sh script.sh anotherawsesomeapp

ตัวอย่าง:

AppName=$1

/usr/bin/systemctl start database@$AppName;
if [ $? != "0" ] 
then; 
    echo "$AppName could not be started. Are you using the right application name?";
fi

1
เช่นนี้มีปัญหาเช่นเดียวกับ sudoers คุณจำเป็นต้องอ้างอิงตัวแปรไม่เช่นนั้นจะถูกแบ่งในช่องว่าง
kyrias

สิ่งนี้จะไม่ทำงาน setuid ไม่ได้รับเกียรติสำหรับเชลล์สคริปต์ (บน Linux)
Martijn

สิ่งที่มันทำคือการใช้ sudo เพื่อรันสคริปต์ มันไม่ได้แตกต่างไปจากนี้เหมือนกันกับสคริปต์ 'hello world' หากรูทสามารถรันสคริปต์มันจะทำงาน
Baazigar

0

วิธีแก้ปัญหาที่เสนอขึ้นอยู่กับSUID

คุณสามารถสร้างสคริปต์ดังกล่าวที่เรียก systemctl ด้วย sudo ทำให้สคริปต์เป็นเจ้าของโดย root ให้SUIDสิทธิ์ในการรูทและอ่านและดำเนินการอนุญาตให้กับกลุ่มผู้ดูแลระบบฐานข้อมูล (dba)
เพียงระวังอย่าให้สิทธิ์ในการเขียนแก่กลุ่มหรือคนอื่น ๆ เพราะวิธีที่พวกเขาอาจเปลี่ยนสคริปต์และทำให้มันดำเนินการใด ๆ ที่นำหน้าด้วย sudo! นอกจากนี้ตรวจสอบให้แน่ใจว่าสคริปต์นั้นเป็นอินพุตแบบพิสูจน์กระสุน

$ cat >> start_database.sh
ฐานข้อมูลเริ่มต้น sudo / usr / bin / systemctl @ $ 1
(Ctrl + D)

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

$ sudo chown root: dba start_database.sh
$ sudo chmod ux, gw, o-rwx start_database.sh
$ sudo chmod u + s, g + rx start_database.sh

จากนั้นเพื่อตรวจสอบสิทธิ์ที่ถูกต้อง:

$ ls -la
.
.
.
-rwSr-x --- 1 root dba 35 ส.ค. 2 19:11 start_database.sh
.
.
.

ดังนั้นการสรุป:

1. owner of the script is root
ไฟล์ 2. ไฟล์can be read and executed by the dba group members
3. no-one else will be able to even readมัน
4. SUIDจะช่วยให้ผู้ใช้ที่เรียกใช้งานสคริปต์กลายเป็นรูทตราบใดที่สคริปต์ทำงาน
5. ดังนั้น sudo จะไม่หยุดสำหรับรหัสผ่าน

ในกรณีใด ๆ ในระบบที่มีผู้ใช้หลายคนต้องระมัดระวังเป็นอย่างมากด้วยSUIDเพราะมันอาจจะออกจากห้องพักสำหรับการละเมิดได้รับอนุญาต


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