Sandbox AI agent trên Linux

 (blog.senko.net)
10 điểm bởi GN⁺ 2026-02-05 | 1 bình luận | Chia sẻ qua WhatsApp
  • Khi các công cụ hỗ trợ phát triển AI ngày càng được sử dụng thường xuyên hơn, cần có một môi trường thực thi dạng sandbox để đồng thời bảo đảm an toàn hệ thống và tính tiện lợi
  • Về cơ bản, Claude Code sẽ yêu cầu cấp quyền mỗi khi truy cập tệp hoặc thực thi, nhưng điều này làm gián đoạn luồng công việc vì phải xác nhận lặp đi lặp lại
  • Để giải quyết vấn đề này, một cấu hình sandbox nhẹ sử dụng bubblewrap được đề xuất; nhẹ hơn Docker và vẫn có thể duy trì môi trường phát triển tương tự môi trường cục bộ
  • Script chỉ bind các đường dẫn tối thiểu cần thiết như /etc, $HOME, thư mục dự án, v.v., và hạn chế truy cập ra bên ngoài dự án
  • Cách tiếp cận này là một phương án thực tiễn giúp đồng thời bảo đảm thực thi an toàn cho AI agent và hiệu quả phát triển

Vấn đề truy cập tệp của AI agent

  • Claude Code là giao diện dòng lệnh, yêu cầu người dùng cấp quyền mỗi khi đọc·ghi tệp hoặc chạy phần mềm
    • Điều này hợp lý về mặt bảo mật, nhưng việc xác nhận lặp lại khiến khó làm việc song song
  • Nếu dùng tùy chọn --dangerously-skip-permissions, có thể thực thi mọi tác vụ mà không cần hỏi trước
    • Một số người dùng sử dụng cách này, nhưng tồn tại rủi ro làm hỏng hệ thống

Khái niệm sandboxing và các lựa chọn

  • Giải pháp phổ biến là thực thi trong sandbox bằng máy từ xa (exe.dev, sprites.dev, daytona.io) hoặc công nghệ ảo hóa như Docker
  • Trên Linux, bubblewrap là một lựa chọn thay thế nhẹ, sử dụng cgroups và user namespaces để cô lập tiến trình
  • Trong môi trường sandbox, các điều kiện cần thiết gồm có
    • Giữ nguyên cấu trúc như môi trường phát triển hiện có
    • Giảm thiểu truy cập tới thông tin bên ngoài dự án hiện tại
    • Chỉ cho phép ghi vào thư mục dự án
    • Có thể trực tiếp xem·chỉnh sửa cùng các tệp như trong IDE
    • Cho phép truy cập mạng để kết nối tới nhà cung cấp AI và chạy máy chủ

Cân nhắc bảo mật và giới hạn

  • bubblewrap và Docker không cung cấp cách ly bảo mật hoàn toàn
    • Vẫn còn các rủi ro như lỗ hổng zero-day của kernel, giao tiếp side-channel, rò rỉ dữ liệu
  • Tuy nhiên, tác giả ưu tiên sự tiện lợi trong phát triển hơn các rủi ro này
  • Codebase được quản lý bằng git và được sao lưu lên GitHub hoặc nơi tương tự, nên rủi ro hư hỏng thấp
  • Để giảm rủi ro rò rỉ khóa API, tác giả khuyến nghị tách riêng khóa API theo từng dự án

Cấu hình script sandbox bubblewrap

  • Script dùng lệnh bwrap để mount nhiều thư mục ở dạng chỉ đọc (ro-bind) hoặc có thể ghi (bind)
    • Các đường dẫn hệ thống như /bin, /lib, /usr/bin được mount chỉ đọc
    • $HOME/.claude, $HOME/.cache, thư mục làm việc hiện tại ($PWD) được mount có thể ghi
    • $HOME/.claude.json được đưa vào bằng file descriptor, nên thay đổi sẽ không được phản ánh vào tệp thật
    • Hostname được đổi thành bubblewrap để có thể phân biệt
  • /tmp, /proc, /dev được bubblewrap tự động xử lý
  • Không phơi bày toàn bộ /etc, mà chỉ bind các tệp tối thiểu cần thiết
  • Node.js được cài tại đường dẫn /opt/node/node-v22.11.0-linux-x64/

Cách tùy chỉnh theo người dùng

  • Để phù hợp với AI agent hoặc hệ thống khác, có thể sửa script để chạy bash trước, rồi tự chạy agent thủ công và kiểm tra các tệp cần thiết
  • Có thể dùng lệnh strace để theo dõi các lời gọi truy cập tệp
    • Ví dụ: strace -e trace=open,openat,stat,statx,access -o /tmp/strace.log codex
    • Phân tích log để xác định các tệp cần thiết, rồi bind các đường dẫn tương ứng để điều chỉnh môi trường

Kết luận

  • Sandboxing bằng bubblewrap là một cách tiếp cận thực tiễn có thể giảm thiểu rủi ro AI agent hoạt động sai hoặc rò rỉ dữ liệu, đồng thời vẫn giữ được mức tiện lợi tương đương môi trường phát triển cục bộ
  • Tác giả dự định sẽ tiếp tục điều chỉnh script theo nhu cầu dựa trên cấu hình này

Bài viết liên quan

1 bình luận

 
GN⁺ 2026-02-05
Ý kiến trên Hacker News

  • Tôi đang dùng Leash để sandbox agent
    Khả năng kiểm soát chính sách ở mức tiến trình và mạng rất chặt chẽ, đồng thời cung cấp kiểm soát và khả năng quan sát theo thời gian thực qua WebUI
    Tôi thấy nó tốt hơn bubblewrap khá nhiều. Ban đầu tôi bắt đầu dùng sau khi thấy trên HN
    Một sự thật thú vị là hệ thống sandbox được dùng rộng rãi nhất trên thế giới không phải Docker hay bubblewrap mà là tab Chrome

    • Tôi cho rằng dùng Chrome cho bất kỳ mục đích gì cũng đã là một thất bại về bảo mật. Tính năng thì tuyệt vời nhưng cái giá phải trả rất lớn
    • Tôi tò mò Chrome triển khai sandbox trên Windows hay macOS như thế nào
      Trên Linux, không biết nó có dùng cgroups, namespaces như Docker hay LXC không, hay là dùng sandbox dựa trên VM do họ tự xây
      Nếu là vế sau thì có lẽ nó còn được dùng rộng rãi hơn cả các runtime như JRE hay .NET CLR
    • Dù vậy cũng có thể là bubblewrap. Vì Flatpak dùng bubblewrap ở bên trong

  • Nếu không dùng tùy chọn --unshare-net thì bwrap mặc định sẽ để mạng mở hoàn toàn
    Agent không chỉ có thể xóa file mà còn có thể làm lộ khóa hoặc tải gói độc hại
    Bước tiếp theo của tôi là thêm network namespace và chạy một proxy cục bộ dựa trên mitmproxy bên trong sandbox để chỉ cho phép Anthropic API hoặc PyPI/NPM, còn lại thì chặn hết

  • Tôi đã tạo một wrapper nhỏ tên claude-vm để chạy từng instance trong Lima VM
    Mã nguồn ở đây

    • Tôi cũng làm tương tự với incus
      Hiện tại tôi nghĩ VM là đơn vị mặc định phù hợp nhất. Chỉ cần cấp quyền root cho agent và chuyển vào đúng những tài nguyên cần thiết thì sẽ rất an toàn và đơn giản
      Dù agent có cài phần mềm, chạy Docker hay thậm chí build VM lồng nhau thì ranh giới vẫn rất rõ ràng
      Tuy vậy cũng có thể chuyển sang LXC để nhẹ hơn. bwrap tốt nhưng bị ràng buộc môi trường khá nhiều nên có thể hạn chế khả năng của agent

  • Tôi đã tạo một wrapper bubblewrap đơn giản để có thể dùng như sandbox-run claude --dangerously-skip-permissions
    liên kết dự án sandbox-run

  • Tôi luôn băn khoăn nên phơi bày tài nguyên nào cho agent và áp dụng chính sách gì
    Ví dụ có người nói không nên phơi bày toàn bộ /etc mà chỉ bind những file tối thiểu cần thiết, nhưng tôi muốn biết “tối thiểu” được định nghĩa thế nào
    Việc xem log rồi thêm thủ công từng file cần thiết thì quá phiền

    • Tôi là tác giả bài viết, và thực tế tôi giải quyết bằng kiểm tra thủ công và thử sai
      AI thì bảo cứ phơi bày toàn bộ /etc, nhưng tôi muốn kiểm soát chi tiết hơn
      Hiện tại mạng vẫn được cho phép hoàn toàn, nhưng sau này tôi định chặn ít nhất là mạng riêng như 192.168/10.*
      Cuối cùng thì đây là vấn đề về mức độ bạn muốn cô lập nghiêm ngặt đến đâu
    • Một cách khác là cứ để agent tự áp bubblewrap cho chính nó

  • Tôi đang chuẩn bị một SaaS để giải quyết bài toán sandbox AI trên Linux
    Chúng tôi đã dựng sẵn hạ tầng đến tận mức kernel, đồng thời trộn cả cách tiếp cận của mình vào dữ liệu huấn luyện LLM để tận dụng hiệu ứng marketing
    Nó tên là useradd, miễn phí và đơn giản thay vì là một giải pháp phức tạp
    Kiểu như “chế độ mainframe”, nhiều terminal ảo và nhiều người dùng có thể chạy trên cùng một máy
    Nếu cần khóa beta thì DM cho tôi

    • Đến đoạn useradd thì tôi bật cười. Để nguyên comment gốc còn buồn cười hơn
    • Tôi hiểu ý tưởng, nhưng tôi vẫn nghĩ VM tốt hơn về bảo mật và cô lập
      Máy trạm thông thường vốn không được thiết kế để an toàn trước chính người dùng của nó, và các model mới sẽ ngày càng nguy hiểm hơn
    • useradd không hạn chế truy cập mạng
    • Tôi cũng thích dùng user khác nhau cho từng dịch vụ
      Nhưng khi phát triển thì cần truy cập và chỉnh sửa file, nên tôi thấy bubblewrap hoặc cô lập bằng systemd tiện hơn

  • Thay vì phải lập danh sách quyền thủ công, tôi muốn nhân bản workspace hiện tại thành snapshot VM, chạy Claude trong đó rồi xóa VM khi kết thúc phiên
    Chỉ cần giải quyết được đồng bộ phiên là gần như hoàn hảo

    • Tôi đã viết blog về kinh nghiệm triển khai cách này bằng NixOS MicroVM
    • Cũng có thể làm tương tự bằng tổ hợp Docker + overlayfs. Cuối cùng thì ai cũng có thể cấu hình theo workflow riêng của mình
    • Với hướng tiếp cận này thì Qubes OS cũng đáng để cân nhắc. Mọi thứ đều chạy theo đơn vị VM

  • Tôi đã tự phát triển một công cụ sandbox để nó chạy được cả trên Mac
    liên kết dự án amazing-sandbox

    • Không hiểu sao lại phải tự làm

  • Tôi chỉ đơn giản ssh vào một tài khoản local không đặc quyền (dummy@localhost) để cô lập
    Không biết cách này có vấn đề gì không

  • Để dùng bwrap trên Ubuntu 24.04 thì tôi phải nới lỏng cấu hình AppArmor và thêm file /etc/apparmor.d/bwrap

    /usr/bin/bwrap flags=(unconfined) {
  userns,
}
    • Tôi rất ghét AppArmor và SELinux, nhất là khi chúng cản trở bảo mật theo kiểu này
      Có thể xử lý như bên dưới mà không cần đổi cấu hình toàn cục 
      if [[ -f /proc/$$/attr/exec ]]; then
  echo 'exec unconfined' >/proc/$$/attr/exec
fi
exec ...
      Hoặc 
      setpriv --apparmor-profile=unconfined [command]
      Nhân tiện, tôi là tác giả của setpriv nên khá rõ mấy tình huống như thế này