Currently, zhm runs as root and handles network traffic; any sandboxing we can get at all is a positive development. This PR implements a basic seccomp-bpf filter for zhm using libseccomp. The filter still allows a lot of potentially dangerous operations (e.g., unlink(2)), but it does block stuff like ptrace(2), so it’s a definite improvement over nothing at all.
The filter is based partly on a close reading of the zhm and libhesiod source code and partly on empirical evidence from running zhm under strace(1). I’ve run zhm with this filter for several days without incident, but some edge cases (e.g., server failover) are still untested.
This PR also enables seccomp in Debian builds, which breaks building on kFreeBSD, but Zephyr didn’t build there anyway to begin with, so I don’t feel too bad about it. In any case, it shouldn’t be too hard to conditionalize the libseccomp-dev dependency on being on Linux; I didn’t do it here because it’s simpler this way.
Currently, zhm runs as root and handles network traffic; any sandboxing we can get at all is a positive development. This PR implements a basic seccomp-bpf filter for zhm using libseccomp. The filter still allows a lot of potentially dangerous operations (e.g., unlink(2)), but it does block stuff like ptrace(2), so it’s a definite improvement over nothing at all.
The filter is based partly on a close reading of the zhm and libhesiod source code and partly on empirical evidence from running zhm under strace(1). I’ve run zhm with this filter for several days without incident, but some edge cases (e.g., server failover) are still untested.
This PR also enables seccomp in Debian builds, which breaks building on kFreeBSD, but Zephyr didn’t build there anyway to begin with, so I don’t feel too bad about it. In any case, it shouldn’t be too hard to conditionalize the libseccomp-dev dependency on being on Linux; I didn’t do it here because it’s simpler this way.