Privileged LXC บน Proxmox ทำให้ระบบเสี่ยงต่อการเจาะรูท

Lead paragraph ผู้ใช้ Proxmox VE ที่พึ่งพา **Linux Containers (LXC) แบบ privileged เชื่อว่าการรันคอนเทนเนอร์บนระบบบ้านหรือทดลองทำงานจะปลอดภัยและไม่ส่งผลกระทบต่อโฮสต์หลัก อย่างไรก็ตาม รายงานของ XDA‑Developers ระบุว่า การตั้งค่าแบบนี้อาจเป็น “ช่องทางเปิด” ให้ผู้โจมตีเข้าถึงระดับ root ของเครื่องโดยตรง ส่งผลให้ความปลอดภัยของระบบล่มสลายอย่างรุนแรง

Overview

Proxmox VE เป็นแพลตฟอร์ม virtualization ที่รวมคุณสมบัติของ KVM, QEMU และ LXC ไว้ในหนึ่งเดียว ทำให้ผู้ดูแลระบบสามารถสร้างและจัดการเครื่องเสมือนหรือคอนเทนเนอร์ได้จากเว็บอินเตอร์เฟซเดียวตามที่บริษัท Proxmox ระบุ การสนับสนุน LXC นั้นเป็นจุดเด่นสำคัญ เนื่องจากคอนเทนเนอร์ใช้ทรัพยากรระบบอย่างมีประสิทธิภาพ ลดความจำเป็นในการจัดสรร RAM หรือ CPU แยกต่างหากเหมือนกับ VM ปกติ

ในหลายกรณีผู้ใช้งานเลือกใช้ privileged LXC เพื่อให้คอนเทนเนอร์เข้าถึงฟังก์ชันของ kernel ได้เต็มที่ เช่น การทำงานของ systemd, การจัดการอุปกรณ์และ cgroup ต่าง ๆ อย่างไรก็ตาม ความสะดวกสบายนี้มาพร้อมกับความเสี่ยงที่มักถูกประเมินค่าต่ำเกินไปในสภาพแวดล้อมแบบ home‑lab หรือระบบที่มีทรัพยากรจำกัด

How Privileged LXCs Work

Privileged LXC ทำงานโดยแมป UID/GID ของ root ภายในคอนเทนเนอร์ตรงกับ root บนโฮสต์ กล่าวคือ กระบวนการใด ๆ ที่ทำงานในคอนเทนเนอร์ด้วยสิทธิ์ root จะได้รับ สิทธิ์ระดับ kernel เดียวกัน กับระบบหลัก การตั้งค่านี้ทำให้ผู้ดูแลระบบสามารถเรียกใช้คำสั่งเช่น `mount`, `modprobe` หรือจัดการไฟล์ระบบได้โดยไม่มีข้อจำกัด

ในทางเทคนิค LXC ใช้ namespace เพื่อแยกกระบวนการและไฟล์ซิสเต็ม แต่เมื่อเปิดโหมด privileged จะปิดบาง namespace (เช่น user namespace) ทำให้คอนเทนเนอร์ไม่สามารถแยกตัวออกจาก root ของระบบได้อย่างสมบูรณ์ การตั้งค่าแบบนี้จึงเป็น “double‑edged sword” ที่อาจทำให้การโจมตีผ่านช่องโหว่ภายในคอนเทนเนอร์ส่งผลต่อโฮสต์โดยตรง

Security Incident Details

ตามที่ XDA‑Developers รายงาน ผู้เขียนบทความได้ตั้งค่า privileged LXC บน Proxmox VE เวอร์ชันล่าสุดเพื่อรันบริการ FOSS ที่ต้องการสิทธิ์ระดับ systemd – เช่น GitLab Runner และ Gitea หลังจากเปิดใช้งานคอนเทนเนอร์แล้ว เขาพบว่าแอปพลิเคชันหนึ่งภายใน LXC สามารถเรียกใช้สคริปต์ shell ด้วย UID 0 ได้โดยไม่ต้องผ่านการตรวจสอบเพิ่มเติม

เมื่อผู้โจมตีทำการส่ง payload ผ่านบริการเว็บที่รันในคอนเทนเนอร์ พวกเขาสามารถใช้ช่องโหว่ของแอปพลิเคชันนั้นเพื่อเรียก `execve` ด้วยสิทธิ์ root ได้โดยตรง จากนั้นกระบวนการเหล่านั้นถูกขยายไปยังโฮสต์ Proxmox ทำให้ผู้โจมตีสามารถเข้าถึงไฟล์ระบบสำคัญ เช่น `/etc/shadow`, การติดตั้ง backdoor และทำลายข้อมูลที่จัดเก็บบน storage pool ทั้งหมด

เหตุการณ์นี้ชี้ให้เห็นว่า privileged LXC ไม่ได้มีการแยก sandbox อย่างเต็มรูปแบบ ดังนั้นแม้จะดูเหมือน “ไม่มีอะไรน่ากังวล” แต่การผสมผสานระหว่างซอฟต์แวร์ที่อาจมีบั๊กและการกำหนดค่าที่เปิดเผยสิทธิ์ root ทำให้ระบบทั้งหมดเสี่ยงต่อการถูกยึดครอง

Root Causes & Mitigations

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

• การใช้ privileged LXC โดยไม่มีความจำเป็น – บางบริการที่ต้องการ systemd หรืออุปกรณ์พิเศษสามารถทำงานได้บน unprivileged container ด้วยการเพิ่ม capabilities เฉพาะโดยไม่ต้องเปิด root เต็มรูปแบบ
• **ขาดการแยกเครือข่าย (network isolation) – คอนเทนเนอร์หลายตัวแชร์ bridge network เดียวกัน ทำให้ผู้โจมตีสามารถสแกนและเข้าถึงบริการอื่น ๆ ได้ง่ายขึ้น
• อัปเดตแพทช์ไม่ทัน – เวอร์ชัน Proxmox ที่ใช้งานอยู่ไม่ได้รับการอัปเกรดเป็นเวอร์ชันที่รวม security fix สำหรับ LXC namespace handling

เพื่อบรรเทาความเสี่ยง ผู้ดูแลระบบควรดำเนินการตามขั้นตอนต่อไป

• ปรับคอนฟิกให้ใช้ unprivileged LXC โดยเพิ่ม `features: "nesting=1"` หรือ `cap_add` เฉพาะที่จำเป็น
• แยกเครือข่ายของแต่ละคอนเทนเนอร์ด้วย VLAN หรือ firewall rules เพื่อลดการสื่อสารระหว่างคอนเทนเนอร์โดยไม่ต้องการ
• ตรวจสอบและอัปเดต Proxmox VE อย่างสม่ำเสมอ รวมถึงติดตั้ง security patches ของ LXC kernel modules

Recommendations for Users

สำหรับผู้ใช้ระดับมือใหม่หรือผู้ที่จัดทำ home‑lab การเลือกใช้ Docker หรือ Podman บนโหมด rootless อาจเป็นทางเลือกปลอดภัยกว่าในกรณีที่ต้องการความเบาและแยก sandbox อย่างชัดเจน นอกจากนี้ ควรปฏิบัติตามแนวทาง “least privilege” โดยให้แต่ละบริการทำงานด้วยสิทธิ์ต่ำสุดที่จำเป็น

หากต้องการใช้ LXC จริง ๆ ควรดำเนินการตรวจสอบต่อไปนี้ก่อนเปิดใช้งาน

• ตรวจสอบไฟล์คอนฟิก `/etc/pve/lxc/<id>.conf` เพื่อยืนยันว่าไม่มี `privileged: 1` หากไม่จำเป็น
• ใช้เครื่องมือเช่น AppArmor หรือ SELinux เพื่อล็อกการทำงานของกระบวนการภายในคอนเทนเนอร์
• ตั้งค่า log monitoring บน Proxmox เพื่อจับสังเกตเหตุการณ์ที่อาจบ่งชี้การละเมิดสิทธิ์ (เช่น การเรียก `chroot` หรือ `mount` จากคอนเทนเนอร์)

การทำตามขั้นตอนเหล่านี้จะช่วยลดความเสี่ยงจากการโจมตีผ่านช่องโหว่ของ privileged LXC และเพิ่มระดับความมั่นใจในการใช้ Proxmox VE เป็นแพลตฟอร์ม virtualization หลักในสภาพแวดล้อมที่ต้องการความคุ้มค่า

Impact

เหตุการณ์ที่เกิดขึ้นทำให้ชุมชนผู้ใช้ Proxmox ต้องทบทวนแนวคิดเรื่อง “ความปลอดภัยของคอนเทนเนอร์บนโฮสต์เดียว” อย่างจริงจัง ผลกระทบโดยตรงได้แก่

• การสูญเสียข้อมูลสำคัญจาก storage pool ที่ถูกเข้าถึงโดยผู้โจมตี
• ความเสี่ยงต่อการเปิดเผยคีย์ส่วนตัวและ credential ของบริการที่รันใน LXC เช่น Git repository, CI/CD pipeline
• ลดความเชื่อมั่นขององค์กรขนาดเล็กหรือสตาร์ทอัพที่พึ่งพา Proxmox เป็นโซลูชันต้นทุนต่ำ

อย่างไรก็ตาม การตอบสนองโดยการออก patch จากทีมพัฒนา Proxmox และการเผยแพร่แนวทางปฏิบัติที่ปลอดภัยบนฟอรั่มต่าง ๆ ช่วยให้ผู้ใช้สามารถปรับตัวและต่อสู้กับความเสี่ยงได้เร็วขึ้น

Summary

การใช้ privileged LXC บน Proxmox VE แม้จะสะดวกแต่มีช่องโหว่ด้าน security ที่อาจทำให้ระบบทั้งหมดถูกยึดครองได้ ผู้ใช้งานควรพิจารณาเปลี่ยนเป็น unprivileged container, แยกเครือข่ายและอัปเดตซอฟต์แวร์อย่างต่อเนื่องเพื่อป้องกันเหตุการณ์คล้ายคลึงนี้ในอนาคต.