tracing: add flags to reject policies with signal and override actions #2850
Conversation
This patch allows disabling of the 2 action types that allow modification of syscall behaviour. This is desirable in certain scenarios to prevent privilage escalation via loading policies via the gRPC API. This patch implements this by adding 2 flags to the tetragon binary --disable-signal-actions which causes tetragon to reject any policy that specifies `Signal` or `Sigkill` actions --disable-override-actions which causes tetragon to reject any policy that specifies `Override` actions Rejection was preferred over silent removal of the disabled actions from the policy as that will have less unexpected behaviour. Signed-off-by: Ben Segall <[email protected]>
✅ Deploy Preview for tetragon ready!
To edit notification comments on pull requests, go to your Netlify site configuration. |
|
Note that the grpc can be restricted by |
|
This is not sufficient if we want a client running as a user to be able to stream events from tetragon |
kkourt
added
the
release-note/minor
| case "sigkill": | ||
| if option.Config.DisableSignalActions { | ||
| return fmt.Errorf("sigkill actions are disabled") | ||
| } | ||
| case "signal": | ||
| if option.Config.DisableSignalActions { | ||
| return fmt.Errorf("signal actions are disabled") | ||
| } |
There was a problem hiding this comment.
nit: combine these two cases into a single case since they seem to be checking the same thing.
There was a problem hiding this comment.
I would also say, would we want to group these two options so that we don't end up with "too many flags"? Is it very likely that someone that would use one would like to use the other?
There was a problem hiding this comment.
I just meant that having something like:
case "sigkill", "signal":
...
|
Thanks for the PR. Having a switch for the use-case you describe makes sense to me. Can you please have a look at the GH action failures? There seems to be a typo in one of the commit messages:
And you need to run |
Well I see two separate things here:
From the privilege escalation perspective: these actions are just the aggressive ones, with ebpf you can attach anywhere, could probably sniff anywhere and get an escalation without performing any action. So I would say for time being this flag can make sense, what about following
We will add new actions in the future and for this: 1. Users won't have to update their config if they care, and 2. We can't just base the fact these two actions are special where you are loading full bpf programs. |
Fixes
Description
This patch allows disabling of the 2 action types that allow modification of syscall behaviour.
This is desirable in certain scenarios to prevent privilage escalation via loading policies via the gRPC API.
This patch implements this by adding 2 flags to the tetragon binary
--disable-signal-actionswhich causes tetragon to reject any policythat specifies
SignalorSigkillactions--disable-override-actionswhich causes tetragon to reject any policythat specifies
OverrideactionsRejection was preferred over silent removal of the disabled actions from the policy as that will have less unexpected behaviour.
Changelog