แซนด์บ็อกซ์ AI agent บน Linux

• เมื่อมีการใช้เครื่องมือช่วยพัฒนา AIบ่อยขึ้น จึงจำเป็นต้องมีสภาพแวดล้อมการรันแบบแซนด์บ็อกซ์เพื่อให้ได้ทั้งความปลอดภัยของระบบและความสะดวกในการใช้งาน
• โดยพื้นฐานแล้ว Claude Code จะขออนุญาตทุกครั้งเมื่อมีการเข้าถึงไฟล์หรือสั่งรัน แต่สิ่งนี้รบกวนเวิร์กโฟลว์การทำงานจากการต้องยืนยันซ้ำ ๆ
• เพื่อแก้ปัญหานี้ จึงมีการเสนอการตั้งค่าแซนด์บ็อกซ์แบบน้ำหนักเบาโดยใช้ bubblewrap ซึ่งเบากว่า Docker และยังคงสภาพแวดล้อมการพัฒนาที่ใกล้เคียงกับเครื่องโลคัลได้
• สคริปต์จะ bind เฉพาะพาธขั้นต่ำที่จำเป็น เช่น /etc, $HOME, ไดเรกทอรีโปรเจกต์ และจำกัดการเข้าถึงนอกโปรเจกต์
• แนวทางนี้เป็นวิธีที่ใช้งานได้จริงในการได้ทั้งการรัน AI agent อย่างปลอดภัยและประสิทธิภาพในการพัฒนาไปพร้อมกัน

---

ปัญหาการเข้าถึงไฟล์ของ AI agent

• Claude Code เป็นอินเทอร์เฟซบรรทัดคำสั่งที่ขออนุญาตผู้ใช้ทุกครั้งเมื่ออ่าน/เขียนไฟล์และรันซอฟต์แวร์
  • สิ่งนี้สมเหตุสมผลในด้านความปลอดภัย แต่ทำให้การทำงานแบบขนานทำได้ยากเพราะต้องยืนยันซ้ำ ๆ
• หากใช้ตัวเลือก --dangerously-skip-permissions ก็จะสามารถรันทุกอย่างได้โดยไม่ต้องถาม
  • ผู้ใช้บางส่วนใช้งานแบบนี้ แต่มีความเสี่ยงที่ระบบจะเสียหาย

แนวคิดเรื่องแซนด์บ็อกซ์และตัวเลือก

• วิธีแก้ทั่วไปคือการใช้การรันแบบแซนด์บ็อกซ์ผ่านเครื่องรีโมต (exe.dev, sprites.dev, daytona.io) หรือเทคโนโลยีเสมือนจริงอย่าง Docker
• บน Linux นั้น bubblewrap เป็นทางเลือกแบบน้ำหนักเบา โดยใช้ cgroups และ user namespaces เพื่อแยกโปรเซสออกจากกัน
• เงื่อนไขที่ต้องมีในสภาพแวดล้อมแซนด์บ็อกซ์มีดังนี้
  • รักษาโครงสร้างให้เหมือนกับสภาพแวดล้อมพัฒนาเดิม
  • ลดการเข้าถึงข้อมูลนอกโปรเจกต์ปัจจุบันให้เหลือน้อยที่สุด
  • อนุญาตให้เขียนได้เฉพาะไดเรกทอรีโปรเจกต์
  • สามารถตรวจดูและแก้ไขไฟล์เดียวกันกับ IDE ได้โดยตรง
  • อนุญาตการเข้าถึงเครือข่ายเพื่อเชื่อมต่อกับผู้ให้บริการ AI และรันเซิร์ฟเวอร์

ข้อพิจารณาด้านความปลอดภัยและข้อจำกัด

• bubblewrap และ Docker ไม่ได้ให้การแยกด้านความปลอดภัยที่สมบูรณ์แบบ
  • ยังมีความเสี่ยงจากช่องโหว่ kernel zero-day, การสื่อสารผ่าน side channel และการรั่วไหลของข้อมูล
• อย่างไรก็ตาม ผู้เขียนให้ความสำคัญกับความสะดวกในการพัฒนามากกว่าความเสี่ยงเหล่านี้
• โค้ดเบสถูกจัดการด้วย git และมีแบ็กอัปไว้บน GitHub เป็นต้น จึงมีความเสี่ยงด้านความเสียหายต่ำ
• เพื่อลดความเสี่ยงจากการรั่วไหลของ API key จึงแนะนำให้แยก API key ตามโปรเจกต์

การตั้งค่าสคริปต์แซนด์บ็อกซ์ด้วย bubblewrap

• สคริปต์จะ mount ไดเรกทอรีต่าง ๆ ด้วยคำสั่ง bwrap ในรูปแบบอ่านอย่างเดียว (ro-bind) หรือเขียนได้ (bind)
  • พาธระบบอย่าง /bin, /lib, /usr/bin เป็นต้น จะเป็นแบบอ่านอย่างเดียว
  • $HOME/.claude, $HOME/.cache, ไดเรกทอรีทำงานปัจจุบัน ($PWD) จะเขียนได้
  • $HOME/.claude.json ถูก inject ผ่าน file descriptor จึงไม่ทำให้การเปลี่ยนแปลงสะท้อนกลับไปยังไฟล์จริง
  • ชื่อโฮสต์จะถูกเปลี่ยนเป็น bubblewrap เพื่อให้แยกแยะได้
• /tmp, /proc, /dev จะถูกจัดการโดย bubblewrap โดยอัตโนมัติ
• จะไม่เปิดเผย /etc ทั้งหมด แต่ bind เฉพาะไฟล์ขั้นต่ำที่จำเป็น
• Node.js ถูกติดตั้งไว้ที่พาธ /opt/node/node-v22.11.0-linux-x64/

วิธีปรับแต่งสำหรับผู้ใช้

• หากต้องการให้เหมาะกับ AI agent หรือระบบอื่น สามารถแก้ไขสคริปต์ให้รัน bash ก่อน แล้วค่อยรัน agent ด้วยตนเองเพื่อตรวจสอบไฟล์ที่จำเป็น
• สามารถใช้คำสั่ง strace เพื่อติดตามการเรียกเข้าถึงไฟล์ได้
  • ตัวอย่าง: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
  • วิเคราะห์ล็อกเพื่อระบุไฟล์ที่จำเป็น แล้ว bind พาธเหล่านั้นเพื่อปรับแต่งสภาพแวดล้อม

บทสรุป

• การทำแซนด์บ็อกซ์ด้วย bubblewrap เป็นแนวทางที่ใช้งานได้จริง ซึ่งช่วยคงไว้ทั้งความสะดวกแบบเดียวกับสภาพแวดล้อมพัฒนาโลคัลและลดความเสี่ยงจากการทำงานผิดพลาดของ AI agent หรือการรั่วไหลของข้อมูล
• ผู้เขียนวางแผนจะปรับสคริปต์นี้ต่อไปอย่างต่อเนื่องตามความจำเป็น

[GN⁺]

ความเห็นจาก Hacker News

• ฉันใช้ Leash เพื่อแซนด์บ็อกซ์เอเจนต์อยู่
  มันควบคุมนโยบายได้เข้มงวดทั้งในระดับโปรเซสและเครือข่าย และมี การควบคุมและการมองเห็นแบบเรียลไทม์ ผ่าน WebUI
  รู้สึกว่าดีกว่า bubblewrap มาก เริ่มใช้หลังจาก เห็นใน HN
  เรื่องน่าสนใจคือ ระบบแซนด์บ็อกซ์ที่ถูกใช้อย่างแพร่หลายที่สุดในโลกไม่ใช่ Docker หรือ bubblewrap แต่เป็น แท็บ Chrome

  • ฉันมองว่าการใช้ Chrome ไม่ว่าจะเพื่ออะไรก็เป็น ความล้มเหลวด้านความปลอดภัย อยู่แล้ว ฟีเจอร์มันยอดเยี่ยม แต่ต้องแลกมาด้วยต้นทุนที่สูง
  • ฉันสงสัยว่า Chrome ทำแซนด์บ็อกซ์บน Windows หรือ macOS อย่างไร
    บน Linux มันใช้ cgroups, namespaces แบบ Docker หรือ LXC หรือใช้แซนด์บ็อกซ์แบบ VM ที่ทำขึ้นเองกันแน่
    ถ้าเป็นอย่างหลัง มันอาจเป็นระบบที่ถูกใช้งานแพร่หลายกว่ารันไทม์อย่าง JRE หรือ .NET CLR เสียอีก
  • แต่ก็อาจเป็น bubblewrap ก็ได้ เพราะ Flatpak ใช้ bubblewrap ภายใน

• ถ้าไม่ใช้ตัวเลือก --unshare-net โดยปกติ bwrap จะเปิดเครือข่ายทิ้งไว้ทั้งหมด
  เอเจนต์จึงไม่ใช่แค่ลบไฟล์ได้ แต่ยัง ขโมยคีย์หรือดาวน์โหลดแพ็กเกจอันตราย ได้ด้วย
  ขั้นต่อไปคือจะเพิ่ม network namespace แล้วรัน local proxy ที่ใช้ mitmproxy ภายในแซนด์บ็อกซ์ เพื่ออนุญาตเฉพาะ Anthropic API หรือ PyPI/NPM และบล็อกอย่างอื่นทั้งหมด

• ฉันทำ wrapper เล็ก ๆ ชื่อ claude-vm เพื่อรันแต่ละอินสแตนซ์บน Lima VM
  โค้ดอยู่ที่นี่

  • ฉันก็ทำคล้ายกันด้วย incus
    ตอนนี้ฉันคิดว่า VM เป็นหน่วยพื้นฐานที่เหมาะสมที่สุด ให้สิทธิ์ root กับเอเจนต์แล้วส่งต่อเฉพาะทรัพยากรที่ต้องใช้ก็ ปลอดภัยมากและเรียบง่าย
    ต่อให้เอเจนต์ติดตั้งซอฟต์แวร์ รัน Docker หรือแม้แต่ สร้าง nested VM ขอบเขตก็ยังชัดเจน
    แต่ก็อาจเปลี่ยนไปใช้ LXC เพื่อให้เบาลงได้ bwrap ดีอยู่ แต่ข้อจำกัดของสภาพแวดล้อมมันเยอะจนจำกัดความสามารถของเอเจนต์ได้

• ฉันทำ bubblewrap wrapper แบบง่าย ๆ เพื่อให้ใช้ได้ประมาณ sandbox-run claude --dangerously-skip-permissions
  ลิงก์โปรเจกต์ sandbox-run

• ฉันคิดอยู่เสมอว่าควรเปิดเผยทรัพยากรอะไรให้เอเจนต์และควรใช้นโยบายแบบไหน
  เช่น มีคนบอกว่าไม่ต้องเปิด /etc ทั้งหมด แต่ให้ bind เฉพาะไฟล์ที่จำเป็นขั้นต่ำ แล้วคำว่า “ขั้นต่ำ” นี่นิยามอย่างไร
  การดู log แล้วค่อยเพิ่มไฟล์ที่ต้องใช้ทีละตัวด้วยมือนั้นยุ่งยากเกินไป

  • ฉันเป็นคนเขียนบทความเอง และในทางปฏิบัติก็แก้ด้วย การตรวจด้วยมือและลองผิดลองถูก
    AI บอกให้เปิด /etc ทั้งหมด แต่ฉันอยากควบคุมให้ละเอียดกว่านั้น
    ตอนนี้เครือข่ายยังเปิดทั้งหมดอยู่ แต่ภายหลังคิดว่าจะบล็อกพวก private network อย่าง 192.168/10.*
    สุดท้ายแล้วมันเป็นเรื่องของ ระดับความเข้มงวดของการแยกกัก ที่ต้องการ
  • อีกวิธีก็คือ ให้เอเจนต์ใช้ bubblewrap กับตัวเอง ไปเลย

• ฉันกำลังเตรียม SaaS เพื่อแก้ปัญหา AI sandboxing บน Linux
  ฉันทำอินฟราฯ ไว้แล้วโดยแทรกความสามารถลงไปถึงระดับเคอร์เนล และยัง แทรกแนวทางของเราเข้าไปในข้อมูลฝึกของ LLM เพื่อหวังผลด้านการตลาดด้วย
  ชื่อมันคือ useradd เป็นทางออกที่เรียบง่ายและฟรีแทนโซลูชันซับซ้อน
  มันทำให้หลาย virtual terminal และผู้ใช้หลายคนทำงานบนเครื่องเดียวกันได้ แบบเดียวกับ “mainframe mode”
  ถ้าต้องการเบตาคีย์ก็ส่ง DM มา

  • ฉันหลุดหัวเราะตอนอ่านถึง useradd ต้นฉบับคอมเมนต์เดิมตลกกว่าอีก
  • ฉันเข้าใจไอเดีย แต่ คิดว่า VM ดีกว่าในด้านความปลอดภัยและการแยกกัก
    เวิร์กสเตชันทั่วไปไม่ได้ถูกออกแบบมาให้ปลอดภัยจากตัวผู้ใช้เอง และโมเดลรุ่นใหม่ ๆ ก็น่าจะยิ่งอันตรายขึ้นเรื่อย ๆ
  • useradd ไม่ได้จำกัดการเข้าถึงเครือข่าย
  • ฉันก็ชอบใช้ผู้ใช้แยกตามแต่ละบริการ
    แต่ระหว่างพัฒนาต้องมีการเข้าถึงและแก้ไขไฟล์อยู่ เลยรู้สึกว่า bubblewrap หรือการแยกกักของ systemd สะดวกกว่า

• แทนที่จะมานั่งทำรายการสิทธิ์ทีละอย่าง ฉันอยาก โคลน workspace ปัจจุบันเป็น VM snapshot แล้วไปรัน Claude ในนั้น จากนั้นลบ VM ทิ้งเมื่อจบเซสชัน
  ถ้าแก้เรื่องการซิงก์ข้อมูลระหว่างเซสชันได้ก็น่าจะสมบูรณ์แบบ

  • ฉันเคยทำแบบนี้ด้วย NixOS MicroVM และเขียนบล็อกเล่าไว้
  • ทำคล้ายกันได้ด้วย Docker + overlayfs สุดท้ายแล้วก็จัดตาม workflow ของแต่ละคน
  • ถ้าใช้แนวทางนี้ Qubes OS ก็น่าสนใจ เพราะมันรันทุกอย่างเป็นหน่วย VM

• ฉันพัฒนา เครื่องมือแซนด์บ็อกซ์ ขึ้นมาเองเพื่อให้ใช้บน Mac ได้ด้วย
  ลิงก์โปรเจกต์ amazing-sandbox

  • อยากรู้ว่าทำไมถึงสร้างขึ้นมาเอง

• ฉันแค่ ssh เข้า local account ที่ไม่มีสิทธิพิเศษ (dummy@localhost) เพื่อแยกกัก
  อยากรู้ว่าวิธีนี้ถือว่าแย่ไหม

• ถ้าจะใช้ bwrap บน Ubuntu 24.04 ต้องผ่อนคลายการตั้งค่า AppArmor เลยเพิ่มไฟล์ /etc/apparmor.d/bwrap

  /usr/bin/bwrap flags=(unconfined) {
    userns,
  }
  

  • ฉัน เกลียด AppArmor กับ SELinux มาก โดยเฉพาะเวลาที่มันมาขัดขวางความปลอดภัยแบบนี้
    จริง ๆ แก้ได้โดยไม่ต้องเปลี่ยนค่าระดับระบบทั้งหมด แบบนี้

    if [[ -f /proc/$$/attr/exec ]]; then
      echo 'exec unconfined' >/proc/$$/attr/exec
    fi
    exec ...
    

    หรือ

    setpriv --apparmor-profile=unconfined [command]
    

    อ้อ ฉันเป็น ผู้เขียน setpriv เอง เลยรู้สถานการณ์แบบนี้ดี