การนำ Landlock มาใช้กับ Linux

 (blog.prizrak.me)
1 คะแนน โดย GN⁺ 2025-12-01 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Landlock ทำให้แอปพลิเคชันประกาศทรัพยากรที่สามารถเข้าถึงได้อย่างชัดเจน เพื่อให้สามารถทำ self-sandboxing ได้ที่ระดับเคอร์เนล
  • เรียบง่ายกว่า SELinux และ AppArmor และสามารถสร้างและใช้นโยบายที่ runtime โดยไม่ต้องใช้สิทธิ์ผู้พัฒนา
  • นโยบายกำหนดเป็น allowlist ชัดแจ้งสำหรับไฟล์·ไดเรกทอรี·พอร์ตที่สามารถเข้าถึงได้ และการจำกัดแบบลำดับชั้นช่วยเสริมความปลอดภัยได้แบบค่อยเป็นค่อยไป
  • มี bindings สำหรับ Rust, Go, Haskell และสามารถใช้งานกับแอป GUI, เซิร์ฟเวอร์, โปรเซสเดสก์ท็อป ฯลฯ เพื่อทำการควบคุมการเข้าถึงแบบละเอียดได้
  • ในระบบนิเวศความปลอดภัยของ Linux เป็นเครื่องมือ sandboxing โดยไม่ใช้สิทธิ์พิเศษที่เรียบง่ายและใช้งานได้จริง และกำลังเป็นองค์ประกอบสำคัญในการเสริมความปลอดภัยด้านเดสก์ท็อปในอนาคต

ภาพรวมของ Landlock

  • Landlock คือ API ที่ทำให้แอปพลิเคชัน Linux ต้องประกาศทรัพยากรที่สามารถเข้าถึงได้
    • คล้ายแนวคิด unveil() และ pledge() ของ OpenBSD และใช้หลักการ “อนุญาตเฉพาะทรัพยากรที่จำเป็น”
  • ให้เลเยอร์ป้องกันที่เป็นมิตรกับนักพัฒนา โดยเข้าใจและผสานง่ายกว่าเมคานิซึมความปลอดภัยของ Linux เดิม
  • จุดมุ่งหมายคือการสนับสนุนการใช้ Landlock ไปพร้อมกับแนวทางประกาศทรัพยากรที่เข้าถึงได้อย่างชัดเจน

วิธีการทำงาน

  • ใช้รูปแบบ Linux Security Module (LSM) และพร้อมใช้งานตั้งแต่ Linux 5.13
  • ต่างจาก SELinux และ AppArmor ตรงที่เป็น การจำกัดชั่วคราวระดับกระบวนการ (transient restriction)
    • นโยบายถูกสร้างใน runtime และใช้กับเธรดปัจจุบันและกระบวนการลูกเท่านั้น เมื่อกระบวนการจบลงจะหายไป
  • องค์ประกอบของนโยบาย
    1. Handled accesses: ประเภทงานที่จำกัด (เช่น การอ่าน/เขียนในระบบไฟล์)
    2. Access grants: รายการวัตถุที่อนุญาตอย่างชัดเจน
  • ตัวอย่างนโยบาย
    • อ่านอย่างเดียวที่ /home/user
    • อ่าน/เขียนที่ /tmp
    • อนุญาตให้ bind พอร์ต 2222
  • เมื่อเรียก landlock_restrict_self() เธรดดังกล่าวและกระบวนการลูกจะเข้าสู่โหมดจำกัดถาวร
    • ข้อจำกัดไม่สามารถยกเลิกได้ และซ้อนชั้นได้สูงสุด 16 ชั้น
    • ชั้นล่างสามารถลดการเข้าถึงเพิ่มเติมได้ แต่สิทธิ์ที่เอาออกจากชั้นบนสุดจะไม่สามารถคืนกลับได้
  • ทำงานแบบ ไม่ต้องมีสิทธิ์สูง (unprivileged) ดังนั้นแอปพลิเคชันทั่วไปก็สามารถ sandboxing ตัวเองได้
  • ผ่านการจัดการเวอร์ชัน ABI ทำให้ทำงานได้เท่าที่เป็นไปได้บนเคอร์เนลรุ่นเก่า
  • เป็น Stackable LSM จึงใช้ร่วมกับ SELinux หรือ AppArmor ได้

เหตุผลที่ควรใช้

  • เหมาะกับแอปพลิเคชันที่มีรูปแบบการเข้าถึงไฟล์คาดเดาได้
    • ตัวอย่าง: จำกัดเว็บเซิร์ฟเวอร์ให้เข้าถึงเพียง /var/www/html และ /tmp
  • ไม่ต้องพึ่งการแทรกแซงของผู้ดูแลระบบหรือการตั้งค่าระบบระดับทั้งเครื่อง และกำหนดนโยบายได้โดยตรงในโค้ด
  • ใช้งานได้โดยไม่ต้องเพิ่มสิทธิ์และสามารถผสานเข้ากับโปรแกรมส่วนใหญ่ได้ง่าย
  • มี bindings สำหรับ Rust, Go, Haskell และมีโปรเจกต์ wrapper แบบ unveil หลายตัว
  • ยังไม่มีไลบรารี C อย่างเป็นทางการ แต่สามารถใช้การใช้งานแบบไม่เป็นทางการหลายรายการได้
  • ในโค้ดตัวอย่างของ Rust จะตั้งค่า /usr, /etc, /dev ให้เข้าถึงแบบอ่านอย่างเดียว และ /home, /tmp ให้เข้าถึงแบบอ่าน/เขียนได้

สถานการณ์และความจำเป็นของการ sandboxing บน Linux

  • การใช้งาน Linux เพิ่มขึ้นควบคู่ไปกับมัลแวร์เป้าหมายเดสก์ท็อปที่เพิ่มขึ้น
  • ความปลอดภัยเชิงสัมพันธ์ของ Linux มาจาก ส่วนแบ่งตลาดและอุปสรรคเชิงเทคนิค มากกว่าความปลอดภัยเชิงโครงสร้าง
  • ปัญหาของดิสโทรทั่วไป
    • สามารถรันไบนารีที่ไม่เชื่อถือได้
    • สามารถรันสคริปต์โดยตรงจากอินเทอร์เน็ต
    • ใช้ sudo โดยไม่ต้องมีรหัสผ่าน
    • แอปทั่วไปสามารถเข้าถึงไฟล์สำคัญใน $HOME
    • สามารถสอดแนมการกดแป้นในสภาพแวดล้อม X11
    • สามารถ bind พอร์ตใดก็ได้

ข้อจำกัดของเครื่องมือความปลอดภัยเดิม

  • Containerization (Docker, Podman): เหมาะกับการแยกบริการ แต่ไม่เหมาะกับแอปเดสก์ท็อป และมีกรณีที่ option --privileged ทำให้การแยกตัวถูกหลีกเลี่ยงได้
  • Flatpak / Snap: เหมาะกับแอป GUI แต่มีขอบเขตสิทธิ์กว้างเกินไป และไม่เหมาะกับเครื่องมือ CLI
  • Firejail: ต้องมีโปรไฟล์เฉพาะแอป และต้องเรียกใช้อย่างชัดเจนทุกครั้งที่รัน

มุมมองนักพัฒนาจากกลไกเดิม

  • seccomp: แม้ทรงพลังแต่การตั้งค่าค่อนข้างซับซ้อน และแนวทาง blacklist มีจุดอ่อน
  • SELinux: แม้ทรงพลังแต่ซับซ้อน ต้องการนโยบายจากผู้ดูแลระบบ และดิสโทรหลายตัวปิดใช้งานเป็นค่าเริ่มต้น
  • AppArmor: ง่ายกว่า SELinux แต่ยังคงต้องใช้โปรไฟล์จากผู้ดูแลระบบ และบางดิสโทรปิดใช้งาน

สรุปข้อดีของ Landlock

  • ไม่ต้องมีสิทธิ์สูง, เน้นที่แอปพลิเคชัน, ผสานได้ง่าย, default deny
  • ได้รับการสนับสนุนอย่างแพร่หลาย หลัง Linux 5.13 และคงความเข้ากันได้ทั้งเวอร์ชันเก่าและใหม่
  • แม้ไม่สมบูรณ์แบบ แต่เป็นเครื่องมือ sandboxing แบบไม่ใช้สิทธิ์สูงที่เป็นอิสระและใช้งานได้จริง ช่วยเติมเต็มช่องว่าง

ความเป็นไปได้ในการนำ Landlock ไปใช้

  • สำหรับกระบวนการเดมอนที่มีสิทธิ์สูงในโหมดทำงานยาวนาน สามารถจำกัดขอบเขตการเข้าถึงด้วย Landlock ได้
  • โปรแกรมอ่าน PDF, โปรแกรมดูภาพ, เว็บเบราว์เซอร์, โปรแกรมประมวลผลคำ และอื่น ๆ สามารถจำกัดให้อ่านไฟล์ที่เปิดอยู่เท่านั้น
  • FTP/HTTP server สามารถกำหนดให้เข้าถึงเฉพาะไฟล์ที่จำเป็น
    • ตัวอย่าง: แม้ nginx จะรันด้วยสิทธิ์ root ผู้โจมตีที่ยึด shell ได้ก็ไม่สามารถเข้าถึงไฟล์นอกนโยบายได้
  • หากมีการนำแนวคิด Supervisor เข้ามาใช้ ก็อาจทำให้ระบบสิทธิ์แบบ Android เกิดขึ้นบน Linux desktop
    • เมื่อผสานกับระบบสิทธิ์และระบบจัดเก็บสิทธิ์แบบ GUI ก็สามารถสร้างประสบการณ์ผู้ใช้ที่ปลอดภัยมากขึ้นได้

ฟีเจอร์ที่กำลังพัฒนาใน Landlock

  • Supervise Mode: ตัดสินใจอนุญาต/ปฏิเสธการเข้าถึงแบบโต้ตอบในพื้นที่ผู้ใช้ คล้ายพรอมต์ขออนุญาตแบบ Android
  • Socket Restrictions: ควบคุมชนิดของซ็อกเก็ตและพอร์ตที่กระบวนการสามารถใช้ได้อย่างละเอียด
  • LANDLOCK_RESTRICT_SELF_TSYNC: กระจายข้อจำกัดไปยังเธรดทั้งหมดภายในกระบวนการเดียวกัน
  • LANDLOCK_ADD_RULE_QUIET: ระงับข้อความบันทึก audit สำหรับวัตถุบางรายการ
  • LANDLOCK_ADD_RULE_NO_INHERIT: ป้องกันไม่ให้สิทธิ์จากไดเรกทอรีระดับบนสืบทอดลงไดเรกทอรีย่อย ช่วยควบคุมระบบไฟล์ได้ละเอียดขึ้น

สรุป

  • Landlock คือกลไก sandboxing แบบ default deny ที่เรียบง่ายและอาศัยการทำงานแบบไม่ใช้สิทธิ์สูง
  • เข้าใจและผสานใช้งานได้ง่าย และมีศักยภาพสูงในการยกระดับความปลอดภัยของ Linux desktop และแอปพลิเคชัน
  • นักพัฒนาสามารถนำ Landlock ไปใช้กับแอปพลิเคชันของตนเองได้โดยตรงเพื่อ เพิ่มระดับความปลอดภัย

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2025-12-01
ความคิดเห็นใน Hacker News
  • ฉันใช้ Landlock เพื่อบล็อก telemetry ที่ไม่ต้องการ
    เขียนโปรแกรมง่าย ๆ ด้วย C ให้รับฟังเพียงพอร์ตเดียว และบล็อกการเชื่อมต่อเครือข่ายอื่นทั้งหมด
    อ้างอิงจาก sandboxer.c ตัวอย่าง และควบคุมเฉพาะเครือข่ายโดยไม่แตะข้อจำกัดการเข้าถึงไฟล์
    ใน dmesg จะเห็นการเชื่อมต่อที่ถูกบล็อก ซึ่งน่าจะเป็นเพราะ ความสามารถด้าน audit
    เครื่องมือนี้ทำงานในโหมด ผู้ใช้ที่ไม่มีสิทธิพิเศษ และทำงานได้ดีแม้อยู่ในคอนเทนเนอร์โดยไม่ต้องตั้งค่าไฟร์วอลล์
    แต่ฉันคิดว่ามันไม่เหมาะสำหรับใช้ป้องกันโปรแกรมที่เป็นอันตรายแบบสมบูรณ์
    • อยากรู้ว่าสามารถแชร์ซอร์สโค้ดได้ไหม
  • Landlock ไม่ได้สมบูรณ์แบบ
    จาก issue #28 และเมลเธรดที่เกี่ยวข้อง มีปัญหาว่ากฎ sandbox ไม่สามารถอ้างอิง ไดเรกทอรีที่ยังไม่มีอยู่ ได้
    ตัวอย่างเช่น ถ้าเพิ่มกฎตอนที่ ~/.ssh ยังไม่มีอยู่ ต่อให้สร้างไดเรกทอรีนั้นภายหลังก็จะไม่ถูกบล็อกการเข้าถึง
    กล่าวคืออาจเกิดช่องโหว่ด้านความปลอดภัยได้
  • ฉันกำลังลอง sandbox เกมจาก itch.io ด้วย bwrap
    การรันด้วยสิทธิ์น้อยที่สุดค่อนข้างยุ่งยาก
    “Microlandia” รันไม่ได้ แต่เกม Unity อื่น ๆ ใช้งานได้ดี
    หวังว่าจะมีเครื่องมือที่อิง Landlock มากขึ้นเพื่อให้งานแบบนี้ง่ายขึ้น
  • สงสัยว่าสถานะ การรองรับ ของ Landlock ในคอนเทนเนอร์รันไทม์เป็นอย่างไร
    ดูเหมือนว่า CRI ต่าง ๆ พยายามนิยามอินเทอร์เฟซของตัวเอง แต่ก็คงตามหลังการรองรับในเคอร์เนลเสมอ
    ไม่น่ามีผู้ดูแลโครงสร้างพื้นฐานจำนวนมากที่จะคอยดูแลนโยบาย sandbox แยกตามแอป
    ฉันคิดว่าการให้แอปพลิเคชันใช้ Landlock เองน่าจะเป็นทางเลือกที่เป็นจริงมากกว่า
    • มีการพูดถึง runc issue, runtime-spec issue และอธิบายว่า
      ถ้ารันไทม์แค่ปล่อย system call ผ่านไป ก็จะเกิดปัญหาที่ต้อง เชื่อใจ ให้แอปล็อกตัวเอง
    • ฉันคิดว่าเดิมที Landlock ไม่ได้ถูกออกแบบมา สำหรับคอนเทนเนอร์รันไทม์ แต่เป็นความสามารถที่มีจุดประสงค์อื่น
  • ในฐานะนักพัฒนาอุปกรณ์การแพทย์ ฉันยินดีกับแนวทางแบบนี้มาก
    ภายในเราก็ใช้ API คล้ายกันเพื่อ จัดการโปรเซสสำคัญ
    งานวิจัยแบบนี้จะช่วยอุตสาหกรรมที่มีข้อกำกับดูแลอย่างมาก
  • คำว่า “ไม่มี C library อย่างเป็นทางการ” ฟังดูแปลก
    ถ้าเป็นความสามารถของเคอร์เนล ก็น่าจะมี C API ก่อนอยู่แล้ว เลยสงสัยว่าทำไมถึงไม่มี
    • อินเทอร์เฟซพื้นฐานของเคอร์เนลคือ syscall(uapi)
      libc เป็นเพียงชั้นที่วางอยู่ด้านบน และยังมี syscall จำนวนมากที่ไม่มี wrapper ใน libc มาจนถึงตอนนี้
    • ที่พูดถึงตรงนี้หมายถึง standard C library อย่าง glibc หรือ musl
      จะสร้าง header เองแล้วเรียกผ่านแมโคร _syscallN โดยตรงก็ได้
    • ถึงไม่มี C API ก็ไม่ได้เป็นปัญหาใหญ่
      ใช้ wrapper ง่าย ๆ อย่าง landbox ได้
      และ Rust หรือ Go ก็เปิด C FFI ได้เช่นกัน
      แค่อ้างอิง ตัวอย่าง sandboxer.c ของเคอร์เนล ก็เพียงพอแล้ว
    • เนื้อหาส่วนใหญ่สรุปไว้ใน เอกสาร man7
    • นักพัฒนาเคอร์เนลไม่ได้สร้าง ซอฟต์แวร์ฝั่งยูสเซอร์แลนด์ โดยตรง จึงไม่มี C API
  • ควรระวังว่า Landlock จำกัดได้แค่ TCP socket และ ไม่บล็อก UDP หรือ raw socket
    • นั่นดูเหมือนจะเป็น ช่องโหว่ด้านความปลอดภัย ที่ค่อนข้างใหญ่ สงสัยว่าเหตุผลคืออะไร
    • raw socket ต้องใช้สิทธิ์ และสามารถบล็อกตาม UID ด้วย iptables ได้
      แม้จะต่างจาก Landlock แต่ก็ใช้เสริมกันได้
    • ถึงอย่างนั้นก็ยังรู้สึกว่าเป็นช่องโหว่ค่อนข้างใหญ่
    • เป็นข้อจำกัดที่แปลก แต่ก็ดีที่รู้ไว้
  • น่าสนใจที่ Landlock เพิ่ม syscall ใหม่ แทนการตั้งค่าผ่าน /sys
    น่าจะเป็นเพราะ หลักการไม่ใช้สิทธิพิเศษ
    แล้วก็สงสัยว่าสามารถบล็อก Landlock syscall ด้วย seccomp ได้ไหม
    ถ้านโยบาย seccomp เก่าไม่มีหมายเลข Landlock อยู่ อาจทำให้เกิด SIGSYS ได้หรือเปล่า?
    • LSM อื่น ๆ ก็เริ่มขยับไปใช้ syscall เป็นฐานมากขึ้นเรื่อย ๆ
      API แบบระบบไฟล์มี footgun เยอะ และการควบคุมการเข้าถึงแบบอิง dirfd ก็เหมาะกับ syscall มากกว่า
      seccomp filter ที่เขียนมาดีจะคืนค่า -ENOSYS ทำให้ดูเหมือนแค่ว่า “ไม่รองรับ”
    • แม้จะจำกัด Landlock syscall ด้วย seccomp ได้ แต่ในทางปฏิบัติประโยชน์ไม่มาก
      เพราะ Landlock มีไว้เพื่อลดสิทธิ์ที่มีอยู่เท่านั้น ไม่ได้มอบสิทธิ์ใหม่
  • ฉันเพิ่งเริ่มสนใจความปลอดภัยบนลินุกซ์
    กำลังเตรียมย้ายออกจาก Mac มาลินุกซ์เต็มตัว และอยากรู้ว่า Landlock จะช่วยเรื่อง การป้องกันมัลแวร์ ได้มากแค่ไหน
    เช่น อยากสร้างสภาพแวดล้อมที่ปฏิเสธการเข้าถึง ~/.ssh โดยอัตโนมัติ
    และอยากรู้ด้วยว่าสามารถใช้ทำ แอป launcher ได้หรือไม่
    • threat model ของ Landlock ไม่ใช่ ตัวมัลแวร์เอง แต่เป็น ช่องโหว่ที่ทำให้รันโค้ดได้ ในแอปปกติ
      ใช้สำหรับให้แอปจำกัดสิทธิ์ที่ไม่จำเป็นของตัวเอง เพื่อไม่ให้ผู้โจมตียึดระบบได้
    • การบล็อกการเข้าถึงอย่าง ~/.ssh ต้องใช้โมเดล MAC อย่าง AppArmor หรือ SELinux
      Landlock มีประโยชน์เมื่อแอปจำกัดตัวเองหรือโปรเซสลูกของตัวเอง
      เช่น npm จำกัด post-install script ให้เข้าถึงได้แค่ไดเรกทอรี build
      เป็น API ที่นักพัฒนาแอปใช้งานโดยตรง คล้าย pledge ของ OpenBSD
      แต่ Linux มีระบบนิเวศที่กระจัดกระจายจึงน่าจะปรับใช้ช้า
      ระหว่างนี้การใช้ในรูปแบบ wrapper หรือ launcher น่าจะเป็นทางเลือกที่เป็นจริงมากกว่า
    • ตัวจัดการแพ็กเกจต้องกำหนดนโยบายสำหรับ build script หรือไม่ก็ผู้ใช้ต้องใช้ wrapper เอง
      สุดท้ายแล้วมันจะได้ผลก็ต่อเมื่อ โปรแกรมรู้สิทธิ์ของตัวเอง
    • แนวคิดนี้แทบจะเหมือนกับ sandboxing บน macOS และ iOS
      แอประบุรายการทรัพยากรที่ต้องใช้แบบ whitelist ตั้งแต่ต้นการรัน แล้วบล็อกที่เหลือทั้งหมด
      ไม่ได้มีไว้ป้องกันโปรแกรมอันตราย แต่เป็น การปกป้องโปรเซสของตัวเอง
  • คำว่า “ไม่มี C library อย่างเป็นทางการ” ฟังดูน่าขำ
    ใน standard library ก็มี syscall อยู่แล้ว จะต้องมีไลบรารีแยกอีกทำไม?
    เอกสาร man7 ก็มีอยู่แล้ว
    เลยสงสัยว่าหมายถึงแค่อยากได้ ชั้น abstraction หรือไม่
    • libc มีหน้าที่ดูแลหมายเลข syscall และผลข้างเคียงต่าง ๆ
      ดังนั้นที่ glibc ยังไม่ให้ Landlock interface มาก็น่าแปลกใจอยู่
      น่าจะเป็นเพราะปัญหาเรื่อง ความเข้ากันได้กับระบบที่ไม่ใช่ลินุกซ์