Monitoring seccomp violations

[Ian Gudger]

What is the best way to monitor for sentry seccomp violations? I am looking to keep track of both their occurrences and the syscall and args that triggered the violation. I found this commented out line of code that claims to print a stack trace on violation, but this seems to replace the kill action.

[Adin Scannell]

On Wed, Sep 9, 2020 at 2:26 PM Ian Gudger <i...@iangudger.com> wrote:

What is the best way to monitor for sentry seccomp violations? I am looking to keep track of both their occurrences and the syscall and args that triggered the violation. I found this commented out line of code that claims to print a stack trace on violation, but this seems to replace the kill action.

Newer kernels support a seccomp notifier mechanism. This could be plumbed through somewhere (maybe to the containerd shim?):

https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html#userspace-notification

The receiver of that notification would be able to log it, then do whatever they want (e.g. kill the sandbox).

Let us know if that's useful and would love to hear about any plans! :)

-- 

You received this message because you are subscribed to the Google Groups "gVisor Users [Public]" group.
To unsubscribe from this group and stop receiving emails from it, send an email to gvisor-users...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/CANFXSj08jTwz3qVxXio1OcSWsZHSx%2BOwofcWrc0CRWNKKotexQ%40mail.gmail.com.

[Ian Gudger]

That does look useful, thanks!

I think properly surfacing seccomp violations would make open source gVisor significantly more production ready. In addition to security monitoring, it would aid in debugging seccomp violation related bugs.

[Ian Lewis]

Thanks for the feedback. How do you imagine they could be surfaced? One open-sourcey way I can think of would be to expose them via the `runsc events` command which returns container events and could be extended to support something like this. Perhaps eventually it could be part of a proper client library (e.g. gvisor.dev/issue/238). What do you think?

Could you create an issue for this so it could be tracked?

To view this discussion on the web visit https://groups.google.com/d/msgid/gvisor-users/CANFXSj0m2j3kq2w3Bo3e6LqmC%3DhjH4NUjz50WkbPprtkxqB9%2BA%40mail.gmail.com.

--

Ian Lewis |

Developer Advocate |

ianl...@google.com |

+81 (03)4540-2465

[Ian Gudger]

I filed gvisor.dev/issue/3905. I am not sure what the right way to surface this information is. At a minimum it should be logged somewhere. It would also be useful to integrate with a monitoring system of some sort or enable custom integration via some mechanism. The important thing is that if you are seeing your sandboxes being killed, it should be possible to find out why.