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.

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

Add the specification of seccomp userspace notification #1038

Closed

Conversation

KentaTada
Copy link
Contributor

This commit adds the specification of seccomp userspace notification.

The runtime will pass the file descriptor of seccomp notification via the UNIX domain socket using SCM_RIGHT to "listenerPath".
The reference link is below.
https://www.kernel.org/doc/html/v5.0/userspace-api/seccomp_filter.html#userspace-notification

I want to share our background. As Sony, we are building our rootless embedded container system. We need to hook some syscalls like mount(2) or mknod(2) inside our container and handle those syscalls in userspace in accordance with our use case.
I think this specification is useful for all container users, especially rootless container users.

Signed-off-by: Kenta Tada Kenta.Tada@sony.com

@KentaTada
Copy link
Contributor Author

@@ -598,6 +598,9 @@ The following parameters can be specified to set up seccomp:
* `SECCOMP_FILTER_FLAG_TSYNC`
* `SECCOMP_FILTER_FLAG_LOG`
* `SECCOMP_FILTER_FLAG_SPEC_ALLOW`
* `SECCOMP_FILTER_FLAG_NEW_LISTENER`

* **`listenerPath`** *(string, OPTIONAL)* - specifies the path of UNIX domain socket which the runtime will pass the file descriptor of seccomp notification using SCM_RIGHT to.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We may want to prioritize the DLL interface rather than socket. containers/crun#438

cc @giuseppe

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

do you think that should be part of the specs? I considered that more of a development tool. How would the .so handled? Through cgo?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm sorry for the very late reply.
DLL interface is useful but I think we don' t need it as runtime-spec as @giuseppe said.

@alban
Copy link
Contributor

alban commented Sep 15, 2020

Hi @KentaTada. I started a similar proposal and we will discuss this topic at the OCI Weekly Discussion tomorrow. Maybe you can join? Sorry I hadn't noticed this PR before.

@KentaTada
Copy link
Contributor Author

Sorry I hadn't noticed this PR before.

No problem. Thank you for your contact.
I'm sorry but I can't attend the meeting due to personal reasons.
In addition to that, I cannot explain the detailed mechanism of our proprietary container runtime currently.
To put it simply, I implemented it in our container runtime as same as crun.
I think we just only need "listenerPath" like crun as runtime-spec.

BTW, I'll take paternity leaves sometimes and my reply may be late.
@ManaSugi takes over our container runtime and he will reply to the question when I am not available.

@KentaTada
Copy link
Contributor Author

Just rebased

Co-authored-by: Manabu Sugimoto <Manabu.Sugimoto@sony.com>
Signed-off-by: Kenta Tada <Kenta.Tada@sony.com>
@rata
Copy link
Member

rata commented Nov 5, 2020

@KentaTada I've just opened this PR: #1074 that also overlaps.

It is quite similar to this, but it specifies: how the UNIX socket should be used, and more importantly for our use case a seccomp state to be sent over the socket, so the agent can have information about the container (like the pod it is, etc.).

IIUC, it should allow for your use case too. What do you think? Please feel free to review it :)

@rata
Copy link
Member

rata commented Aug 13, 2021

PR #1074 added support for this (is already merged). I think it is safe to close this one :)

@tianon tianon closed this Aug 13, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants