Open
Conversation
Prevent zhm from doing some evil things while it runs (e.g., ptracing) by implementing a basic seccomp-bpf filter. The filter still allows a lot of potentially dangerous operations (e.g., unlink(2)), but this is a good start. 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. I’ve run zhm with this filter for several days without incident, but some edge cases (e.g., server failover) are still untested. configure decides whether or not to enable seccomp by looking for libseccomp. By default, it treats seccomp as an enhancement and enables it opportunistically. Builders can force seccomp to be enabled or disabled by passing --with-seccomp or --without-seccomp, respectively, to configure.
Commit 22a59d2 added basic seccomp support to zhm. Since zhm currently runs as root and handles network traffic, any sandboxing we can get is a good idea. Take a dependency on libseccomp-dev and enable seccomp support for zhm. This breaks building on kFreeBSD, but this package doesn’t currently build there anyway, so it’s not making things any worse.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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.