HYBRID MIND · INTERACTIVE EXPLAINER · 12 ตุลาคม 2026
Plimsoll: มี Sandbox
ไม่ได้แปลว่าได้ขอบเขตที่คิด
Docker รับ flag จำกัด process ได้ แต่ใครเป็นคนบังคับมัน? รายงานใหม่ของผู้พัฒนา Plimsoll ชวนแยกชื่อ runtime ค่าที่ร้องขอ และหลักฐานที่ตรวจได้จริง
QUICK ANSWER
สิ่งที่ต้องรู้ก่อนให้ Agent รันโค้ด
ข่าวใหม่: Carroll Guertin เผยแพร่บันทึกการวัดลงวันที่ 11 ตุลาคม 2026 และเพิ่มเข้า repository ด้วย commit วันที่ 12 ตุลาคม อธิบายว่า Docker ยอมรับ --pids-limit แต่ runtime แต่ละตัวไม่ได้บังคับหรือแสดงค่าที่ชั้นเดียวกัน นี่เป็นรายงานของผู้พัฒนา ไม่ใช่การเปิดตัวรุ่นใหม่วันนี้หรือผล audit อิสระ บันทึกต้นฉบับ
Plimsoll ทำอะไร: เป็นชั้นรับคำขอและรายงานหลักฐานหน้าผู้ให้บริการ sandbox ไม่ได้สร้างกำแพง isolation เอง ผู้เรียกกำหนดขั้นต่ำที่ยอมรับได้ ส่วนผลรายงาน tier และ client ตรวจหลักฐานที่กลับมาอีกครั้ง ขอบเขตที่โครงการนิยาม
สำคัญอย่างไร: ชื่อ VM/container ไม่ตอบทุกคำถาม ต้องแยกกำแพง isolation เพดานทรัพยากร สิทธิ์เรียก API และสถานะว่าโค้ดเริ่มรันแล้วหรือยัง
ยังไม่พิสูจน์: tier อิงการตั้งค่า รายงานของ provider และการตรวจ startup ไม่ใช่ attestation จากฮาร์ดแวร์ โครงการระบุว่าไม่มี third-party security audit และเราไม่ได้ติดตั้งหรือทำซ้ำการวัด sandbox นี้ ข้อจำกัดด้านความปลอดภัย
NEW NOTE · DEVELOPER-REPORTED MEASUREMENT
รับ flag ไม่เท่ากับบังคับ limit
ผู้เขียนตั้งเพดาน process เป็น 64 แล้วลองเริ่ม sleep 200 process บนแล็ปท็อปเครื่องเดียว ใช้ Docker 29.1.3, gVisor release-20260907.0 และ Kata 4.2.0 รายงานนี้ไม่ระบุรายละเอียด CPU/OS ครบพอให้เราอ้างว่าเครื่องอื่นจะให้ตัวเลขเดียวกัน และไม่ได้เป็น benchmark ประสิทธิภาพหรืออันดับความปลอดภัย วิธีวัดและโปรแกรมต้นฉบับ
| runtime ในรายงาน | สิ่งที่รายงานว่าพบ | ข้อควรอ่านประกอบ |
|---|---|---|
| runc | เริ่มได้ 57 จากที่ลอง 200; อ่าน pids.max ได้ 64 | thread ของ Node อยู่ในงบเดียวกัน จึงไม่ใช่ “64 guest process” |
| gVisor | guest อ่าน pids.max เป็น max; ผู้เขียนนับได้ 14 จาก probe ที่ log ทุก spawn | probe หลักตายก่อนพิมพ์สรุปสุดท้าย ไม่ใช่การนับ final stdout แบบเดียวกับทุกแถว |
| Kata ในการตั้งค่าที่ลอง | เริ่มได้ทั้ง 200; guest ไม่ได้ PID limit ตามที่ขอ | ผู้เขียนใช้ Go shim สำหรับ Docker ที่ deprecated และเล่าว่าพบคล้ายกันกับ Cloud Hypervisor ไม่ใช่ทุก deployment |
ภายใต้ gVisor ค่า limit อยู่ใน host cgroup ของ sandbox นั้น และ budget รวม task ของ runtime กับ guest การอ่านไฟล์จำลองใน guest อย่างเดียวจึงตอบผิดชั้นได้ ส่วน Kata ยังมีขอบเขต VM อยู่ การไม่บังคับ guest PID cap ในการตั้งค่าที่รายงาน ไม่ได้แปลว่าโค้ดหลุด VM แล้ว
โค้ด checkPidsLimit ปฏิเสธค่าที่อ่านไม่ได้หรือไม่ตรงที่ตั้ง ส่วน hostPidsMaxPath ตรวจว่า cgroup path ระบุ container ID ที่กำลังตรวจ ไม่ใช่หยิบค่าของ process อื่นมาเป็นหลักฐาน การตรวจนี้มีอยู่ในโค้ดที่อ่าน ไม่ใช่ข้อกล่าวอ้างว่าเพิ่งแก้ช่องโหว่ใหม่วันที่ 12 ตุลาคม ฟังก์ชันต้นฉบับ
มีรายงาน upstream แต่ไม่ใช่การยืนยันทุกตัวเลข
Kata issue #13824 รายงานปัญหา PID limit ในอีกสภาพแวดล้อม: runtime-rs กับ Cloud Hypervisor บน 4.1.0 โดยเปิดไว้ตั้งแต่ 13 กันยายนและยังติดป้าย needs-review ตอนที่อ่าน เป็นรายงานปัญหาต้นฉบับจากการตั้งค่าที่ระบุ ไม่ใช่ maintainer verdict ว่าทุกเวอร์ชันผิด และไม่ใช่การทำซ้ำตัวเลข 57/14/200 ภายใต้เงื่อนไขเดียวกัน เราไม่ได้ยืนยันความเป็นอิสระของผู้รายงานจากโครงการ Plimsoll issue ต้นฉบับ
ชื่อ v0.21.0 เป็น release ล่าสุดที่ตรวจพบ ลงวันที่ 9 ตุลาคม ข่าวในบทความนี้คือบันทึกใหม่ที่เพิ่ม 12 ตุลาคม ไม่ได้ย้ายวัน release เก่ามาเป็นวันนี้ release · commit เพิ่มบันทึก
MECHANISM · MINIMUM ≠ GUARANTEE
สี่ tier เป็นศัพท์ของโครงการ ไม่ใช่คะแนนสากล
process / container
WASM ของ Plimsoll คือ QuickJS บน wazero ใน process ของ daemon ไม่ใช่ขอบเขต OS หรือ VM ส่วน Docker runc เป็น container ที่ใช้ host kernel ร่วมกัน เอกสารเตือนไม่ให้ใช้ wasm นี้กับ hostile code
kernel
Docker runsc ถูกรายงานเป็น kernel tier เมื่อการตั้งค่าและการตรวจตามโครงการครบ กำแพงเป็นงานของ gVisor การเห็น executable ชื่อ runsc กับ startup behavior ไม่ใช่หลักฐานจากฮาร์ดแวร์ว่า runtime ไม่ถูกแทนที่
vm
E2B และ Docker Cloud ถูกรายงาน VM tier จาก provider identity และการตรวจพฤติกรรมที่กำหนด ไม่ใช่การวัด hypervisor ของเราหรือ proof ว่า control plane ไม่ถูกโจมตี
คำขอส่ง MinimumIsolation หรือ floor ของตัวเอง daemon เทียบกับ tier ปัจจุบันก่อนส่งไปรัน ถ้าต่ำกว่าขั้นต่ำ เอกสารระบุ ErrInsufficientIsolation และเครื่องหมายว่าไม่ได้ dispatch แต่ถ้าผลกลับมารายงานขอบเขตต่ำกว่าที่ขอ client แจ้ง ErrIsolationEvidenceMismatch หลังจากโค้ดอาจรันแล้ว สองเหตุการณ์นี้ไม่ใช่สถานะเดียวกัน floor ก่อน/หลัง · client ส่ง floor และตรวจ run record
Plimsoll: คำขอ ขอบเขต และหลักฐาน
ภาพฉาย2.5D เลือกโหนดอ่านหน้าที่ ไม่ใช่mesh3DหรือRuntime เส้นเชื่อมไม่ใช่ทุกคำขอต้องผ่านทุกขั้นเมื่อถูกปฏิเสธ
คำขอ
คำขอกำหนด MinimumIsolation ของรอบนี้ ไม่อาศัยเพียง Describe ที่อ่านก่อนหน้า
ขั้นต่ำไม่ใช่ security score
อ่านข้อมูลทั้งหมดแบบข้อความ
- คำขอ — คำขอกำหนด MinimumIsolation ของรอบนี้ ไม่อาศัยเพียง Describe ที่อ่านก่อนหน้า ตรวจรับ: ขั้นต่ำไม่ใช่ security score
- หลักฐาน — หลักฐาน tier อิง configuration, provider และ startup checks ของ daemon ไม่ใช่ hardware attestation ตรวจรับ: ขอบเขต isolation ไม่แทน resource cap
- ก่อนรัน — ต่ำกว่า floor ถูกปฏิเสธก่อน dispatch ตาม contract ต้องผูกเครื่องหมายกับคำขอนั้น ตรวจรับ: ไม่ลดขั้นต่ำหรือเพิ่มสิทธิ์เพื่อให้รัน
- Provider — กำแพงมาจาก provider ที่เชื่อม เช่น container/gVisor/microVM Plimsoll เป็นชั้นหน้าที่รายงาน ไม่สร้างกำแพงเอง ตรวจรับ: process-tier WASM อยู่ใน daemon ไม่ใช่ VM
- ผลกลับ — ผลกลับตรวจ tier/record เพิ่ม error หลังเริ่มงานอาจมีผลข้างเคียงแล้ว จึงไม่ถือทุก error ว่า retry ได้ ตรวจรับ: คำตอบไม่ผูก request ยืนยันว่าไม่รันไม่ได้
Hybrid Mind Video Lab: ภาพฉาย 2.5D เลือกอ่านหน้าที่แต่ละโหนด ไม่ใช่ mesh 3D หรือ Runtime จริง เส้นเชื่อมเป็นแผนที่กลไกและหลักฐาน ไม่ใช่ทุกคำขอต้องรันผ่านทุกโหนดเสมอ
3D VISUALS · INTERACTIVE DYNAMIC VIEW
เปลี่ยน provider แล้ว floor ยังถึงไหม?
เลือก provider กับขั้นต่ำ ฉากมิติ CSS จะแสดง tier และเส้นทาง “ยังไม่ส่งรัน / ถึงขั้นต่ำในแบบจำลอง” ต่างกัน เลือกชั้นเพื่ออ่านข้อจำกัด ไม่ใช่ security score ไม่เรียก provider จริง และสมมติว่าการตรวจยืนยัน provider ตามเอกสารสำเร็จแล้ว
ขั้นต่ำ: kernel
Docker runc
container · ใช้ host kernel
ต่ำกว่าขั้นต่ำ: ไม่ส่งรันในแบบจำลอง
ขอ kernel → ได้ container → ปฏิเสธก่อนส่งรัน
แบบจำลองไม่ตรวจ token, grant, image, capacity, resource limit หรือ attestation และ “ถึงขั้นต่ำ” ไม่แปลว่าอนุญาต deploy หรือรับรองงานจริง
EVIDENCE DESK
error บอกอะไร — และไม่ได้บอกอะไร
โค้ดที่จบด้วย exit code ไม่เป็นศูนย์ยังเป็นผลการรันตามปกติใน contract: โปรแกรมทำงานแล้วแต่ล้มเหลว ไม่ใช่หลักฐานว่า sandbox ไม่ได้เริ่ม ส่วน error ก่อน dispatch ต้องมีเครื่องหมาย NotDispatched กับเหตุผล เช่น isolation หรือ capacity ถึงจะตีความว่ายังไม่มีโค้ดถูกส่งไปผู้รัน Run results contract
เหตุผลยังสำคัญ: ต่ำกว่า floor อาจเลือก backend ที่ถึงขั้นต่ำได้; capacity อาจรอหรือไป backend อื่นตามสิทธิ์ แต่ permission หรือคำขอผิดไม่ได้เป็นเหตุให้ข้ามระบบตรวจไปลองที่อื่น การ retry ที่เหมาะสมไม่ใช่การลด floor หรือขยาย grant เอง
เครื่องหมายต้องเป็นคำตอบของคำขอนี้
เอกสารกำหนดให้ client ส่ง request ID และ daemon echo กลับ ถ้าคำตอบไม่ผูกกับ ID นั้น client ไม่เชื่อเครื่องหมาย “ไม่ได้รัน” เพราะอาจเป็นคำตอบของอีกคำขอ นี่เป็น contract ในต้นฉบับ ไม่ใช่ claim ว่าเราได้ทดสอบเครือข่ายหรือ proxy จริงแล้ว
หลัง dispatch อย่าตีความว่าเริ่มใหม่ได้ทันที
timeout หรือ evidence mismatch อาจเกิดหลังโค้ดทำผลข้างเคียงไปแล้ว ไม่มีเครื่องหมายก็ใช้สถานะอนุรักษนิยมว่าอาจรัน ไม่ใช่สั่งซ้ำอัตโนมัติ ระบบนี้ไม่ได้ให้ exactly-once guarantee กับทุกงาน
| สิ่งที่มี | หลักฐาน | ขอบเขต |
|---|---|---|
| ระดับ isolation/floor | เอกสาร provider กับ request contract | การตั้งค่าและการตรวจที่โครงการกำหนด ไม่ใช่ hardware attestation |
| ตัวเลข process | รายงานผู้พัฒนา 11 ตุลาคม | เครื่อง/รุ่น/วิธีนับนั้น ไม่ใช่ benchmark ความปลอดภัยทุกระบบ |
| Kata upstream issue | รายงานปัญหาในอีกเวอร์ชัน/การตั้งค่า | ไม่ใช่การทำซ้ำ matched test หรือ audit ของ Plimsoll |
| NotDispatched | typed detail ใน source และ contract เรื่อง request ID | ต้องผูกกับคำขอนั้นและอ่าน reason ไม่ถือทุก error ว่าส่งซ้ำได้ |
VISUAL INTERACTIVE · RETRY EVIDENCE
ก่อน retry คุณรู้อะไรเกี่ยวกับรอบที่แล้ว?
เลือกเหตุการณ์จำลองและสถานะ request ID แล้วดูแผนภาพกับข้อสรุปเปลี่ยน ผลเป็นกติกาเชิงคุณภาพจาก contract ไม่ใช่การจำลองเครือข่ายครบระบบ ไม่เรียก Agent ไม่รันโค้ดข่าว และไม่ส่งคำขอซ้ำจริง
ยืนยันตามสมมติฐานว่าไม่เริ่มรัน
ต้องเลือก provider ที่ถึงขั้นต่ำตามสิทธิ์ ไม่ลด floor เพื่อให้รัน
IMPLICATIONS · EDITORIAL INFERENCE
คุณค่าอยู่ที่ขอบเขตที่ตรวจได้ ไม่ใช่คำว่า secure
ผู้ใช้
ข้ออนุมานของเรา: ถ้าผลบอกทั้ง boundary กับขั้นที่ล้มเหลว ผู้ใช้มีข้อมูลตัดสินใจมากกว่าป้าย sandbox อย่างเดียว แต่ไม่ได้แปลว่าต้องเชื่อโค้ดที่ Agent เขียนหรือเอาข้อมูลอ่อนไหวไปลองทันที
นักพัฒนา
แยกก่อน/หลัง dispatch และเก็บคำตอบให้ผูกกับคำขอ การอ่าน Describe เก่าไม่แทน floor ของแต่ละรอบ resource cap ก็ต้องอ่านจากชั้นที่บังคับจริง ไม่ใช่จาก flag ที่ command ยอมรับ
ธุรกิจ
การเลือก provider ต้องมาพร้อมขอบเขตข้อมูล สิทธิ์ API และวิธีตามผลข้างเคียงหลัง timeout เราไม่มีผลทดลองให้สรุปต้นทุนหรือผลเพิ่มความเร็ว และไม่รับรองระบบ production ที่ยังไม่ได้ตรวจ
สิทธิ์ API ยังเป็นทางออกของข้อมูล
SECURITY.md ระบุว่า grant ตรวจ method/route ไม่ได้ตรวจความหมายของข้อมูลทุกชิ้นที่ code ส่ง API ที่อนุญาตจึงอาจได้รับข้อมูลที่ guest อ่านได้ ภายใน budget นั้น การไม่ให้ token เข้า guest ไม่ได้แปลว่าไม่มีข้อมูลออกจาก sandbox ต้องใช้ข้อมูลและปลายทางที่มีสิทธิ์เท่านั้น
output ของ sandbox ไม่กลายเป็นคำสั่งที่เชื่อถือได้
ผลลัพธ์และ artifact อาจมี prompt injection โครงการไม่ได้ตรวจเนื้อหา output ให้ Agent ทุกตัว การคืนผลไม่ควรทำให้ Agent ขยายสิทธิ์หรือเปลี่ยน grant เอง และการขับ Docker daemon เป็นอำนาจสูงใน trusted computing base ไม่หายไปเพราะ guest อยู่ใน container
โครงการยังไม่อ้างการป้องกัน timing/cache side channel ทุก tier และระบุว่าไม่มี security audit อิสระ สิ่งเหล่านี้เป็นข้อจำกัดจากต้นฉบับ ไม่ใช่ข้อยกเว้นเล็กน้อยที่คะแนน tier จะลบได้ ข้อที่ deployment ยังต้องจัดการ
สิ่งที่ควรจับตา
การทำซ้ำ PID-cap ในรุ่นและสภาพแวดล้อมอื่น คำตอบของ upstream ต่อ issue วิธีจัดการ control plane ที่ถูกโจมตี และ audit อิสระที่เผยขอบเขตจริง มีน้ำหนักมากกว่าจำนวนดาวหรือการที่คำสั่ง Docker ไม่ฟ้อง error
สรุป
ข่าวนี้ไม่ใช่ “ได้ sandbox ใหม่แล้วปลอดภัย” แต่คือบทเรียนว่า boundary ที่ขอ limit ที่ตั้ง หลักฐานที่อ่าน และ error ที่รับอยู่คนละชั้น Plimsoll ทำให้คำถามเหล่านั้นปรากฏใน contract มากขึ้น ส่วนความถูกต้องของ runtime ข้อมูล สิทธิ์และผลข้างเคียงยังต้องรับผิดชอบต่อ
อ่านต่อ: MXC: สิทธิ์ Agent · Littleguys: ใครถือหน้าที่หลัง UI
FAQ
ก่อนแปล tier เป็นความปลอดภัย
Plimsoll เปิดตัว v0.21.0 วันนี้หรือไม่?
ไม่ใช่ release ที่อ่านเป็นวันที่ 9 ตุลาคม ส่วนรายงาน process limit ลงวันที่ 11 ตุลาคมและเพิ่มใน repository 12 ตุลาคม
VM tier พิสูจน์ว่า PID limit ถูกบังคับไหม?
ไม่ใช่ wall isolation กับ resource envelope เป็นคนละเรื่อง รายงาน Kata ยังอยู่ใน VM แต่ guest ไม่ได้ PID cap ตามที่ขอในการตั้งค่าที่ลอง ไม่ได้พิสูจน์การหลุด VM
gVisor เริ่มได้ 14 แปลว่าช้าหรือปลอดภัยกว่าไหม?
สรุปไม่ได้ เป็นจำนวน process ในงบ task และวิธีวัดนั้น ไม่ใช่เวลางานหรือคะแนนความปลอดภัย และตัวเลข 14 มาจาก probe ที่ log ทุก spawn ไม่ใช่ summary ของ probe หลัก
WASM ในโครงการนี้คือ VM isolation หรือไม่?
ไม่ใช่ เป็น QuickJS/wazero ใน daemon process ผู้พัฒนาระบุ process tier และเตือนว่าไม่เหมาะกับ hostile code
error ทุกตัว retry ได้ไหม?
ไม่ได้ ต้องรู้ว่าเกิดก่อน dispatch มีเครื่องหมายและผูกกับ request หรือไม่ รวมเหตุผลและสิทธิ์ timeout หรือผลหลักฐานไม่ตรงอาจเกิดหลังรันแล้ว
Lab เป็นผลทดสอบ Plimsoll หรือไม่?
ไม่ใช่ เป็นฉาก 2.5D ภาพมิติ CSS และแบบจำลอง contract เชิงคุณภาพ ไม่มีคำขอจริง ไม่มีการรันโค้ดหรือเขียนระบบภายนอก
PRIMARY SOURCES
แหล่งต้นฉบับและขอบเขตการอ่าน
- Carroll Guertin: Docker accepts –pids-limit — วัด 11 ตุลาคม 2026; เพิ่มผ่าน commit 12 ตุลาคม
- Isolation tiers และ floor — taxonomy/evidence ของโครงการ
- Run results และ request binding — contract ก่อน/หลังรัน
- โค้ดอ่าน PID cap · โค้ด test process budget — อ่านเท่านั้น ไม่ได้รัน test
- client envelope และตรวจ record · typed refusal mapping
- Security policy — ไม่มี independent audit และข้อจำกัดที่ยังเหลือ
- Kata issue #13824 — รายงานอีกสภาพแวดล้อม ไม่ใช่ audit หรือ matched replication
อ่านข้อมูลที่ commit e3881cfee69c6be2ca94a5f828596562a5b0f1eb · ตรวจ 12 ตุลาคม 2026 เวลา 06:24:29 UTC · บันทึก Research Brief ก่อนเขียนและผลิตภาพ ความนิยมใช้เลือกเรื่อง ไม่ใช่หลักฐานความปลอดภัย ภาพทุกใบเป็นภาพแนวคิดจาก imagegen
ใส่ความเห็น