bwrap ddsec
1.0.0
โปรไฟล์ Sandboxing โดยไม่มีสิทธิ์สำหรับ BubbleWrap
เครื่องมือเวลาการดำเนินการคอนเทนเนอร์จำนวนมากเช่น SystemD-NSPAWN, Dockeretc. มุ่งเน้นไปที่การจัดหาโครงสร้างพื้นฐานสำหรับผู้ดูแลระบบและเครื่องมือ orchestration (ตัวอย่างเช่น Kubernettes) เพื่อดำเนินการคอนเทนเนอร์
เครื่องมือเหล่านี้ไม่เหมาะสำหรับการมอบให้กับผู้ใช้โดยไม่มีสิทธิพิเศษเพราะเป็นเรื่องเล็กน้อยที่จะแปลงการเข้าถึงดังกล่าวเป็นเชลล์รูทที่มีสิทธิ์ที่สมบูรณ์ในโฮสต์
มีระบบแยกที่ระดับเคอร์เนล Linux ที่เรียกว่า "ผู้ใช้เนมสเปซ" ช่องว่างชื่อผู้ใช้ที่พยายามอนุญาตให้ผู้ใช้ที่ไม่มีสิทธิ์ใช้ฟังก์ชั่นของคอนเทนเนอร์ แม้ว่าจะมีความคืบหน้าอย่างมีนัยสำคัญ แต่ก็ยังมีข้อกังวลในเรื่องนี้และไม่สามารถใช้ได้สำหรับผู้ใช้ที่ไม่มีสิทธิ์ในการแจกแจงการผลิตหลายอย่างเช่น CentOS / Red Hat Enterprise Linux 7, Debian Jessie ฯลฯ
ดูตัวอย่างเช่น CVE-2016-3135 ซึ่งเป็นช่องโหว่รูทในท้องถิ่นที่ผู้ใช้แนะนำ สิ่งพิมพ์เดือนมีนาคม 2559 นี้มีการสนทนาเพิ่มเติม
BubbleWrap สามารถมองเห็นได้ว่าเป็นการใช้งานทั้งหมดของชุดย่อยของช่องว่างชื่อผู้ใช้ เน้นไปที่ชุดย่อย - เกี่ยวข้องกับ CVE ก่อนหน้านี้ BubbleWrap ก่อนหน้านี้ไม่อนุญาตให้ควบคุม IPTABLES
รหัส BubbleWrap ดั้งเดิมมีอยู่ก่อนที่ช่องว่างชื่อผู้ใช้: สืบทอดรหัสตัวช่วย XDG -App ที่ในทางกลับกันจะถูกรบกวนโดย Linux-user-chroot
ผู้ดูแลเครื่องมือนี้เชื่อว่าแม้เมื่อใช้ร่วมกับซอฟต์แวร์ทั่วไปที่ติดตั้งในการแจกแจงนั้น แต่ก็ไม่อนุญาตให้เพิ่มสิทธิ์ อย่างไรก็ตามมันสามารถเพิ่มความสามารถของผู้ใช้ที่ลงชื่อเข้าใช้เพื่อดำเนินการปฏิเสธการปฏิเสธบริการ
โดยเฉพาะอย่างยิ่ง BubbleWrap ใช้ pr_set_no_new_privs เพื่อปิดการใช้งาน setuid binary ซึ่งเป็นวิธีดั้งเดิมในการออกไปจากสิ่งต่าง ๆ เช่น chroots
โปรแกรมนี้สามารถแชร์ได้โดยเครื่องมือคอนเทนเนอร์ทั้งหมดที่ไม่ได้รูทการดำเนินการเช่น:
Flatpak RPM-Ostree ที่ไม่มีสิทธิ์ BWRAP-OCI เราต้องการให้มีอยู่ในกลุ่ม Kubernetes / Onshift การมีความสามารถที่ผู้ใช้ที่ไม่มีสิทธิ์ใช้ฟังก์ชั่นของคอนเทนเนอร์จะช่วยให้เกิดการตระหนักถึงสถานการณ์การทำให้บริสุทธิ์แบบอินเทอร์แอคทีฟและคล้ายคลึงกัน
BubbleWrap ทำงานโดยการสร้างพื้นที่แอสเซมบลีที่ว่างเปล่าใหม่อย่างสมบูรณ์ซึ่งรูทอยู่ใน TMPFs ที่มองไม่เห็นโฮสต์และจะถูกทำความสะอาดโดยอัตโนมัติเมื่อกระบวนการสุดท้ายสิ้นสุดลง ถัดไปคุณสามารถใช้ตัวเลือกบรรทัดคำสั่งเพื่อสร้างระบบรูทไฟล์และสภาพแวดล้อมกระบวนการและคำสั่งเพื่อดำเนินการในพื้นที่ชื่อ
มีลำดับคำสั่งการสาธิตที่ใหญ่กว่าในซอร์สโค้ด แต่ที่นี่มีเวอร์ชันเล็ก ๆ ที่เรียกใช้งานเชลล์ใหม่นำไฟล์ /USR ใหม่มาใช้ใหม่
BWRAP-RO-BIND /USR /USR-SYMLINK USR /LIB64 /LIB64-PROC /PROC-DEV /DEV-Share-Pid Bash นี่เป็นตัวอย่างที่ไม่สมบูรณ์ แต่มีประโยชน์สำหรับวัตถุประสงค์ในการอธิบาย บ่อยครั้งแทนที่จะสร้างคอนเทนเนอร์โดยใช้แผนผังระบบไฟล์โฮสต์คุณต้องการลงทะเบียนสำหรับ chroot ที่นั่นแทนที่จะสร้างลิงก์สัญลักษณ์ lib64 -> usr/lib64, TMPFs อาจสร้างขึ้นในรูทปลายทางแล้ว
วัตถุประสงค์ของ BubbleWrap คือการดำเนินการแอปพลิเคชันในกล่องทรายซึ่งมีการ จำกัด การเข้าถึงส่วนต่าง ๆ ของระบบปฏิบัติการหรือข้อมูลผู้ใช้เช่นไดเรกทอรีเริ่มต้น
BubbleWrap จะสร้างพื้นที่แอสเซมบลีใหม่เสมอและผู้ใช้สามารถระบุได้อย่างชัดเจนว่าส่วนใดของระบบไฟล์ควรมองเห็นได้ใน Sandbox ไดเรกทอรีใด ๆ ที่ระบุไว้จะถูกติดตั้งโดยรูปแบบที่กำหนดไว้ล่วงหน้าและสามารถอ่านได้เท่านั้น
นอกจากนี้คุณสามารถใช้ฟังก์ชั่นเคอร์เนลเหล่านี้:
ช่องว่างชื่อผู้ใช้ (Clone_Newuser): สิ่งนี้ซ่อนทุกอย่างยกเว้น UID และ Sandbox ปัจจุบัน นอกจากนี้ยังสามารถเปลี่ยนสิ่งที่ค่า UID / GID ควรอยู่ใน Sandbox
IPC Names Spaces (clone_Newipc): กล่องทรายจะได้รับสำเนาของ CPI ในรูปแบบที่แตกต่างกันทั้งหมดเช่นหน่วยความจำที่ใช้ร่วมกัน SYSV และสัญญาณไฟจราจร
PID ชื่อช่องว่าง (clone_newpid): Sandbox จะไม่เห็นกระบวนการใด ๆ นอกกล่องทราย นอกจากนี้ BubbleWrap จะดำเนินการ PID1 เล็กน้อยภายในภาชนะเพื่อจัดการกับข้อกำหนดของการเก็บเกี่ยวเด็กในกล่องทราย สิ่งนี้หลีกเลี่ยงสิ่งที่เรียกว่าปัญหา Docker PID 1
spaces dehttp: //linux.die.net/man/2/clone ชื่อเครือข่าย (clone_newnet): Sandbox จะไม่เห็นเครือข่าย แต่คุณจะมีพื้นที่ชื่อเครือข่ายของคุณเองที่มีอุปกรณ์วนรอบกลับด้านเท่านั้น
UTS ตั้งชื่อพื้นที่ (clone_newuts): กล่องทรายจะมีชื่อโฮสต์ของตัวเอง
ตัวกรอง SECCOMP: ตัวกรอง SECCOMP ที่ จำกัด การโทรไปยังระบบที่สามารถดำเนินการได้ในโซนทดสอบสามารถผ่านได้ สำหรับข้อมูลเพิ่มเติมดู SECCOMP
Firejail นั้นคล้ายกับ Flatpak ก่อนที่ BubbleWrap จะถูกแบ่งออกเป็นความรู้สึกว่ามันรวมเครื่องมือ setuid เข้ากับฟังก์ชั่น Sandboxing เดสก์ท็อปเฉพาะจำนวนมาก ตัวอย่างเช่น Firejail รู้ Pulseaudio ในขณะที่ BubbleWrap no
ผู้เขียน BubbleWrap เชื่อว่ามันง่ายกว่ามากในการตรวจสอบโปรแกรม setuid ขนาดเล็กและรักษาลักษณะเช่นการกรอง pulseaudio เป็นกระบวนการที่ไม่มีสิทธิพิเศษเช่นนี้ใน Flatpak
นอกจากนี้ @cgwalters คิดว่าการพยายามรวมเส้นทางไฟล์ในรายการสีขาวเป็นความคิดที่ไม่ดีเนื่องจากวิธีการมากมายที่ผู้ใช้ต้องจัดการเส้นทางและวิธีการมากมายที่ผู้ดูแลระบบสามารถกำหนดค่าระบบได้ วิธี BubbleWrap คือการรักษาความสามารถของ Linux เฉพาะบางอย่างเช่น CAP_SYS_ADMIN แต่เข้าถึงระบบไฟล์เสมอเช่นการเรียกใช้ UID สิ่งนี้จะปิดการโจมตี TOCTTOU และคนอื่น ๆ อย่างสมบูรณ์
Sandstorm.io ต้องการช่องว่างสำหรับชื่อผู้ใช้โดยไม่มีสิทธิ์ในการกำหนดค่า Sandbox แม้ว่ามันจะสามารถปรับให้เข้ากับการทำงานในโหมด Setuid ได้อย่างง่ายดาย @cgwalters เชื่อว่ารหัสของมันค่อนข้างดี แต่ก็ยังสามารถรวมกันใน BubbleWrap อย่างไรก็ตาม @kentonv (จากพายุทราย) รู้สึกว่าแม้ว่าสิ่งนี้จะสมเหตุสมผลในหลักการ แต่ค่าใช้จ่ายของการเปลี่ยนแปลงเกินกว่าผลประโยชน์ในทางปฏิบัติในตอนนี้ การตัดสินใจครั้งนี้สามารถประเมินใหม่ได้ในอนาคต แต่วันนี้มันไม่ได้ถูกนำไปใช้อย่างแข็งขัน
ขณะนี้ RunC กำลังทำงานเกี่ยวกับการสนับสนุนคอนเทนเนอร์โดยไม่ต้องรูทโดยไม่จำเป็นต้องได้รับสิทธิพิเศษอื่น ๆ ในระหว่างการติดตั้ง RUNC (ใช้ช่องว่างชื่อผู้ใช้โดยไม่มีสิทธิ์แทนที่จะเป็น setuid) การสร้างและการบริหารคอนเทนเนอร์ อย่างไรก็ตามโหมดมาตรฐานของการใช้ RUNC นั้นคล้ายคลึงกับ SystemD NSPawn ซึ่งได้รับการออกแบบให้ถูกเรียกใช้โดยรูท
ผู้เขียน BubbleWrap เชื่อว่า RUNC และ SystemD-NSPawn ไม่ได้ถูกออกแบบมาให้กลายเป็น setuid และยังห่างไกลจากการยอมรับวิธีการดังกล่าว อย่างไรก็ตามด้วยคอนเทนเนอร์ที่ไม่มีรูท RUNC สามารถปฏิบัติตามกรณีการใช้งานบางอย่างที่ยอมรับโดย BubbleWrap (ด้วยประโยชน์เพิ่มเติมของการเป็นเวลาดำเนินการ OCI ที่สมบูรณ์และเป็นมาตรฐาน)
Binctr เป็นเพียงซองจดหมายสำหรับ RUNC ดังนั้นเขาจึงสืบทอดการชดเชยการออกแบบทั้งหมดของเขา
