Skip to content

[Request]: expose noNewPrivileges and seccomp in the API #551

@almet

Description

@almet

Feature or enhancement request details

Hi folks!

I'd like a way to specify a noNewPrivileges: Bool and a seccomp: LinuxSeccomp? property, so that callers of this library can pass those settings through to the OCI runtime spec that gets executed inside the VM.

Both fields already exist in ContainerizationOCI (Process.noNewPrivileges and
Linux.seccomp) — the missing piece is that the higher-level Swift API doesn't surface them, so library consumers have no way to set them.

My plan would be to have a way to set these attributes when generating the OCI image, and then on top of that make changes to the apple/container repo so that it makes good use of them, and expose it.

Why this matters — the Dangerzone use case

Dangerzone is a security tool from Freedom of the Press Foundation that converts potentially malicious documents (PDFs, Office files, images) into safe PDFs by processing them inside an isolated container. The threat model is explicit: the document being converted may be hostile, crafted specifically to escape the sandbox. Keeping the container process as locked-down as possible is therefore not optional — it is the whole point of the tool.

Dangerzone runs on Linux (Docker/Podman), and we've started experimenting apple/container support for macOS, which relies on this library. On every other container runtime it uses the following security flags unconditionally:

security_args = ["--security-opt", "no-new-privileges"]
security_args += ["--security-opt", f"seccomp={seccomp_json_path}"]
security_args += ["--cap-drop", "all"]
security_args += ["--cap-add", "SYS_CHROOT"]

Without noNewPrivileges and a custom seccomp profile, a container process that is compromised by a malicious document could potentially escalate privileges or make syscalls that are not needed for legitimate rendering work, widening the attack surface. These two controls are the last line of defense after capability dropping.

Hope it makes sense! I believe we could add this behavior in a way that doesn't make changes to the default behavior, but I have limited understanding of the current codebase, and so let me know if I'm missing something!

Thanks!

Code of Conduct

  • I agree to follow this project's Code of Conduct

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions