Sandboxing AI Tools with Guix Containers

26 points by munen

Sanity

Interesting. I’m using firejail after a tip from someone here, and have one emacs instance with net access and only access to a few select directories, and one with filesystem access but no net access. I copy-paste code back and forth when I use llm’s, I don’t like giving full access to private code to openai etc. Maybe a bit paranoid, but there have been so many scary attacks these last few years, I feel like it’s only a matter of time until somone finds the url to archive.openai.com/management/heapdump

munen
firejail looks very interesting! I tried to set up a profile to check it out, but I failed(; If you’d be open to share your configuration, I would be thankful. I only managed to get the most simple command running: firejail --private=~/src/200ok/organice emacs. That worked, but of course it lacked a lot (configuration files, x11, network, commandline tools like grep, etc). I tried reading the web doc and the manpage and asked claude and gemini for help. No dice(;

As for sharing code to llms, I share your general sentiment. I have the the following mitigations:
1. I pay for the APIs, so they should not™ save my data for training.
2. I make sure that the read_file tool cannot open certain files similar to aiderignore[a].
3. I don’t use proprietary ai assistants for which I cannot inspect what exactly happens and which files will be read/changed.
Having said so, for FLOSS on Github, the ship has sailed anyway. So all code could be made accessible to the LLM. And for our proprietary code, there’s always the chance that someone tested a tool which did not conform to rule 3, unfortunately. Which is not saying that the argument is not valid and important. In fact, I think that makes it even more important to safeguard for the future.

a. https://github.com/munen/emacs.d/?tab=readme-ov-file#gptel-read-file-ignore-patterns
- Sanity
  I’m not 100% sure firejail is the best option for my use-case. Firejail has been around for a long time and obviously covers many situations, has a lot of docs, but it feels like the surface area is too big, and there is some automagic complexity in the configuration, I don’t feel completely confident in it. Some of it may be because emacs just does so much, there are a lot of cases to consider (e.g. sockets for emacsclient should only be accessible to that instance, native-compile needs write access). But also I found that in a profile that was supposed to be whitelisting-based (ie. you need to explicitly whitelist a dir to include it), a convenience symlink I had from /foo to $HOME/files/foo wasn’t blocked by firejail. That was a scary surprise when I noticed. And opening an url with xdg-open required some special setup, though I guess it would no matter what solution you use.
  
  I’ve read that bubblewrap may be a cleaner design, though I haven’t found time to look into it yet. Would be interesting to see some example configs if people use emacs through bwrap.
  
  My current firejail configs:
  
  emacs.local, this one overrides stuff from /etc/firejail/emacs.profile:
  
  env FIREJAIL_PROFILE=edit net none # for letting gdb disable ASLR: allow-debuggers noblacklist /sbin noblacklist /usr/sbin noblacklist ${HOME}/.bash_history noblacklist ${HOME}/.local noblacklist ${HOME}/.local/share noblacklist ${HOME}/.local/share/Trash noblacklist ${HOME}/.local/share/Trash/files # These four allow opening (firefox) links with xdg-open: ignore noroot dbus-user.talk org.freedesktop.portal.Desktop env XDG_CURRENT_DESKTOP= env DE=flatpak # For gpg, needed to list /run/user/1000/gnupg (gpg-agent): writable-run-user # but then we need to ensure this profile can't reach the socket of # the other emacs daemon (would be safer if we could just whitelist # the files we need? but then need to rewrite emacs.profile to be # whitelisting): blacklist /run/user/1000/emacs/online nowhitelist /run/user/1000/emacs/online # For gpg, needed to open the secret key: noblacklist ${HOME}/.gnupg # maybe avoid hanging procs: ignore nonewprivs
  
  emacs-online.profile – this is a fresh profile
  
  env FIREJAIL_PROFILE=online # symlink attack :< blacklist /foo whitelist ${HOME}/.emacs.d read-only ${HOME}/.emacs.d whitelist ${HOME}/.emacs.d/eln-cache-online read-write ${HOME}/.emacs.d/eln-cache-online whitelist ${HOME}/bin/emacs read-only ${HOME}/bin/emacs whitelist ${HOME}/.Mail read-write ${HOME}/.Mail # These four allow opening (firefox) links with xdg-open: ignore noroot dbus-user.talk org.freedesktop.portal.Desktop env XDG_CURRENT_DESKTOP= env DE=flatpak # Stuff from /etc/firejail/emacs.profile but commented out so we have net access: #caps.drop all netfilter nodvd nogroups #nonewprivs #noroot notv novideo #protocol unix,inet,inet6 #seccomp # emacs backups are in /tmp/emacs-backups private-tmp
  
  I start two emacs daemons with different socket names:
  
  /usr/bin/firejail --profile=emacs \ emacsclient \ -s edit \ --alternate-editor="" \ "$@" /usr/bin/firejail --profile=emacs-online \ emacsclient \ -s online \ --alternate-editor="" \ "$@"
  
  and from my init.el I can check (getenv "FIREJAIL_PROFILE") to have different color themes for each (and disable stuff that isn’t supported, to avoid warnings).
  - munen
    
    Thank you kindly for sharing your solution🙏
    
    It helped a lot! In the end, I went with bubblewrap. I’m really, really happy with this solution. I have the ability to share certain configs as read-only, and most importantly have all userspace tools inside the container (for example for clojure and nodejs, things that would be hard to do in Guix).
    
    Here’s the script that I’ll be using from here on out: https://github.com/munen/dotfiles/blob/master/bin/bin/bubblewrap-container
    
    I wasn’t aware of either firejail or bubblewrap so far. You helped me a lot, thank you very much🙇
    
    Sanity
    
    No problem, and thanks for sharing your brwap config, maybe I’ll finally attempt that too :-)
    
    munen
    
    Good luck and have fun!
    
    For now, I don’t see any additional requirements to change the config, but if I will, I’ll update the repo, too. If you have a good find about bubblewrap or a completely different approach, feel free to ping me on Github, anytime(;
    
    In any case: Happy hacking^^