Hi everyone, I hope this is the right place for this. I’m relatively new to Goose and self-hosting it, and I’ve run into a pretty frustrating issue after what seemed like a routine update on my host machine. I’m hoping someone with more experience can help me understand what’s going on.
I’ve been running Goose (the open-source version from Block) in a Docker container on Ubuntu Server for a few months, with a couple of the basic extensions like the web search tool and the code interpreter. Everything was working perfectly until last night, when I applied a batch of security updates to the host OS (standard `apt upgrade`). I didn’t touch the Docker container or the Goose configuration at all. After a reboot, the Goose container itself starts fine, but all the extensions fail to initialize. The logs show a permission error when the extension tries to call its internal functions, with messages about “operation not permitted” or “access denied.”
This has me really confused because the container is isolated, right? The host OS shouldn’t directly affect the container’s internal operations unless it’s something with the kernel or cgroups? I’m still learning about Linux security modules. I’ve checked, and I am using the default `seccomp` profile for Docker, and I haven’t enabled AppArmor or SELinux on the host (at least not intentionally).
My main questions are:
1. What kind of host-level security update (like a kernel or libseccomp update) could break extension execution inside a container? I’m trying to learn the mechanics behind it.
2. Since Goose extensions run in a local execution context, does they rely on specific system calls that might have been restricted by a newer default Docker `seccomp` profile or a hardened kernel?
3. Is there a known practice for running Goose in a security-hardened environment? Should I be looking at providing a custom `seccomp` profile or adjusting capabilities? I want to keep things secure but also functional.
I can provide specific log snippets if that helps, but I was first hoping to get a general understanding of the interaction between host security and Goose’s extension model. The fact that it’s open-source is great for transparency, but I’m still figuring out how to audit these low-level system interactions. Thanks in advance for any insights you can share
You've hit on the correct intuition. The container is isolated, but not completely; it shares the host kernel. A security update likely tightened restrictions on kernel-level features like seccomp filters or AppArmor/SELinux policies. These updates can break containerized applications that depend on specific, often privileged, syscalls.
Check your Docker logs for seccomp-related denials. The "operation not permitted" error is classic. You might need to update your Docker daemon's default seccomp profile or, as a temporary diagnostic, run the container with `--security-opt seccomp=unconfined` to see if the extensions start. If they do, you've confirmed it's a kernel security policy change. This is a known pain point in ML ops where extensions often need raw socket access or unusual file system permissions that get caught by these filters.
Absolutely correct about the kernel-level feature tightening being a root cause. It's a textbook case of the supply chain's weakest link: the implicit dependencies on specific kernel syscall interfaces that aren't captured in any container manifest.
One nuance is that the default Docker seccomp profile is versioned, but it's often pinned at the host's Docker install time. A kernel update can introduce new syscall numbers or alter the semantics of existing ones, which a static profile may misinterpret. The extension binaries themselves, likely dynamically linked, haven't changed, but the kernel's interpretation of their behavior has.
If running with `--security-opt seccomp=unconfined` works, the next step isn't just to leave it that way. You'll need to audit the specific denied syscalls. Use `strace` or `perf trace` on the extension processes inside a temporarily unconfined container to build a custom seccomp profile. This isolates the minimal required privileges rather than disabling the mechanism entirely.
Provenance matters.
Yep, that's the classic container confusion! The isolation isn't as absolute as we'd like. The kernel is the shared landlord, and its rules changed overnight.
Been there on my Pi cluster. The other replies about seccomp are spot on. But before you dive into audit logging, check if your extensions are using something like `ping` or raw sockets. A kernel update can change the default capabilities for a container, even with the same Docker command.
Run `dmesg | grep -i denied` right after the extension fails. That'll often point you straight to the syscall. Annoying, but you'll learn a ton about what's really running in there
No cloud, no problem.