Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Surface sentry seccomp violations #3905

Open
iangudger opened this issue Sep 10, 2020 · 4 comments
Open

Surface sentry seccomp violations #3905

iangudger opened this issue Sep 10, 2020 · 4 comments
Labels
area: security Security related issues area: usability Issue related to usability type: enhancement New feature or request

Comments

@iangudger
Copy link
Contributor

If the sentry makes a syscall which is not allowed by its seccomp policy, it is immediately killed. This is required for the security model. Unfortunately, it is difficult to discover which syscall (or argument) triggered the violation. Surfacing this information would be useful for monitoring for potential compromise and bugs in production. The current solution for debugging locally involves uncommenting a line of code and recompiling, which could also be improved upon.

One solution would be using the new seccomp notifier mechanism:
https://www.kernel.org/doc/html/latest/userspace-api/seccomp_filter.html#userspace-notification

This could be used to notify a non-sandboxed process running alongside the sentry of the details of the violation. This information could then be relayed to some monitoring or logging system.
@ianlewis ianlewis added area: security Security related issues area: usability Issue related to usability type: enhancement New feature or request labels Sep 11, 2020
@ianlewis
Copy link
Contributor

One way I thought of to surface this info is to extend runsc events to provide an event when a syscall violation occurred. This would allow support for non-containerd workloads and could be picked up by the shim and relayed back to containerd etc.

It would be even better if we could surface events all the way back up to Kubernetes and surface info in the Kubernetes API.
https://kubernetes.io/docs/tasks/debug-application-cluster/determine-reason-pod-failure/

@fvoznika
Copy link
Member

Seccomp violations are logged to the audit log and it contains information about which syscall hit it:

$ grep SECCOMP /var/log/audit/audit.log
type=SECCOMP msg=audit(1599786866.478:106054): auid=183048 uid=65534 gid=65534 ses=7481 subj==unconfined pid=1901638 comm="exe" exe="/tmp/gv6/runsc" sig=31 arch=c000003e syscall=101 compat=0 ip=0x48c985 code=0x80000000

@iangudger
Copy link
Contributor Author

It doesn't look like it lists the arguments which are important when doing argument-based filtering.

It also doesn't appear to indicate which sandbox the specific violation is associated with.

@ianlewis
Copy link
Contributor

Yeah, not ideal but you could probably identify the sandbox from the pid

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area: security Security related issues area: usability Issue related to usability type: enhancement New feature or request
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@ianlewis @fvoznika @iangudger