seccomp: allow ActNotify if write(2) is in allowed syscalls

[saschagrunert]

We can notify on the default action if write is part of the allowed syscall list. This means that profiles are now able to specify SCMP_ACT_NOTIFY in the default profile action if write(2) is allowed.

cc @mauriciovasquezbernal @haircommander

[kolyshkin]

@rata @alban PTAL

[saschagrunert]

I don't think this works :(

Knowing if a syscall will always be allowed is not that straight forward as what we do here to conclude that. I think this can easily break if write is allowed only with certain params, for example.

Got it, hm… I'll revisit this PR after my vacation ends (2 weeks from now on).

But more importantly, what is the use case? Did you face this limitation or is something you thought "let's remove just remove this" but don't have a use case?

I'm working on an experimental secocmp notifier implementation in CRI-O right now, which right now stops a container once we hit a erroneous syscall (or we could throw metrics later on): https://github.com/cri-o/cri-o/pull/6120.

The runtime/default profile switched to the default action SCMP_ACT_ERRNO since a while:

https://github.com/containers/common/blob/8c1847e01634d88f4488d5f35508d2c939a8d700/pkg/seccomp/seccomp.json#L2-L4

Means we leave a theoretical gap between what we can notify on and what action we hit, so my goal was to close this, but I see that it's hard to achieve. We may consider closing this PR as-is.

[rata]

I'm working on an experimental secocmp notifier implementation in CRI-O right now, which right now stops a container once we hit a erroneous syscall (or we could throw metrics later on): cri-o/cri-o#6120.

Oh, cool. We have implemented something like that too: https://github.com/kinvolk/seccompagent/pull/20 and https://github.com/kinvolk/seccompagent/pull/18. Maybe we can talk on slack to collaborate on something? :) I don't think any of us at Kinvolk is planning to work on this soon, but maybe we can find room to do some collaboration :)

The runtime/default profile switched to the default action SCMP_ACT_ERRNO since a while:

https://github.com/containers/common/blob/8c1847e01634d88f4488d5f35508d2c939a8d700/pkg/seccomp/seccomp.json#L2-L4

Oh, and that profile has write allowed and no args. So the heuristic I mentioned might work for you, maybe that is good enough and is very easy to implement too (we probably need to check for architecture and things like that, though. I see that profile uses non-oci constructs with includes/excludes, so we have to see what OCI seccomp profile it generates).

I think that can work :)

[AkihiroSuda]

Needs rebase

[Zheaoli]

I think maybe I can open a new PR to rebase the main code and change some impl detail and ask review again

[saschagrunert]

I think maybe I can open a new PR to rebase the main code and change some impl detail and ask review again

Sounds good to me, thanks for jumping in!