8000 RFE: Reworking Seccomp Profiles to ENOSYS Default · Issue #42871 · moby/moby · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content
RFE: Reworking Seccomp Profiles to ENOSYS Default #42871
@cyphar

Description

@cyphar

I think we need to rework the approach towards seccomp because the stub workaround I came up earlier this year in opencontainers/runc#2750 seems to not be doing a great job of solving the problem (maybe it's unclear how it works, or maybe the fact you need to be very careful with updating the syscall set in your filter is not being enforced by upstream projects or being missed somehow). In any case, it seems that the setup is just as fragile as it was before but with the added complication that it seems to only break sometimes (because it depends on whether you've included a new syscall without mentioning an old one).

Since Docker is one of the the primary users of runc (alongside containerd, crio, podman, etc) we should probably sit down and unify the rules for seccomp profiles. The only reason we didn't switch to ENOSYS by default is because it would cause existing Docker profiles to change their behaviour. However, with defaultErrnoRet each user of runc can on their own terms switch to a setup where they must explicitly set EPERM for the syscalls they wish to block rather than having this ill-advised setup where syscalls that are not mentioned give you EPERM. The idea was that the ENOSYS-for-syscalls-larger-than-the-largest-specified-in-the-profile behaviour implemented in opencontainers/runc#2750 was meant to be an interim solution until Docker could move to explicitly specifying which syscalls they want to EPERM and the rest should be ENOSYS. Unfortunately that didn't happen.

Basically someone needs to sit down and go through all the syscalls in the Docker profile which are currently not explicitly blocked and add a new EPERM rule for them. There are a few syscalls where this will be complicated or impossible (such as those that have multiple argument matches -- which podman has -- or the clone flag mask case) but we should probably have a discussion whether returning ENOSYS in those cases rather than EPERM is going to be a deal breaker or not. The point is that hopefully we should move all OCI users to defaultErrnoRet: 38 // ENOSYS sooner rather than later if possible.

Originally posted by @cyphar in #42681 (comment)

Metadata

Metadata

Assignees

No one assigned

    Labels

    area/security/seccompkind/enhancementEnhancements are not bugs or new features but can improve usability or performance.

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions

      0