Skip to content

set_secure_computing_mode(SecureComputingMode::Filter) has no filter argument #1451

@rusty-snake

Description

@rusty-snake
Contributor

The C interface looks like

[[deprecated]]
int prctl(PR_SET_SECCOMP, SECCOMP_MODE_FILTER, struct sock_fprog *filter);

however rustix' iterface looks like

set_secure_computing_mode(SecureComputingMode::Filter)

so filter will be some garbage, mostly likely failing with EFAULT.

Since PR_SET_SECCOMP (but not PR_GET_SECCOMP) is deprecated and superseded by seccomp anyway. Do you see a good reason to fix the prctl variant? Or should we just deprecated and later remove the prctl variant in rustix and add support for seccomp(2) as seccomp_set_mode_strict() and seccomp_set_mode_filter(flags, args)?

Activity

sunfishcode

sunfishcode commented on Apr 12, 2025

@sunfishcode
Member

There is a bug here, though it doesn't pass a garbage pointer; it uses prctl_2args which always passes NULL as the remaining arguments.

set_secure_computing_mode does work with SecureComputingMode::Strict, so I think the thing to do is to deprecate just SecureComputingMode::Filter. And yes, I think it's sufficient to just deprecate it. We can always add a new interface in the future, if we get requests for it.

changed the title [-]`set_secure_computing_mode(SecureComputingMode::Filter)` passes a pointer to garbage to the kernel[/-] [+]`set_secure_computing_mode(SecureComputingMode::Filter)` has no filter argument[/+] on Apr 12, 2025
rusty-snake

rusty-snake commented on Apr 12, 2025

@rusty-snake
ContributorAuthor

set_secure_computing_mode does work with SecureComputingMode::Strict

+1

deprecate just SecureComputingMode::Filter

This is still a valid return value of secure_computing_mode(). And actually the only possible return value of secure_computing_mode() other than SecureComputingMode::Disabled.

sunfishcode

sunfishcode commented on Apr 21, 2025

@sunfishcode
Member

This is still a valid return value of secure_computing_mode(). And actually the only possible return value of secure_computing_mode() other than SecureComputingMode::Disabled.

Ah. In that case we probably should deprecate set_secure_computing_mode and define a new function that at least supports the SecureComputingMode::Strict functionality, so that the deprecated message can recommend it as a replacement.

Edit: set_secure_computing_mode is the one that needs to be deprecated because it doesn't work for Filter.

rusty-snake

rusty-snake commented on Apr 21, 2025

@rusty-snake
ContributorAuthor

deprecate secure_computing_mode

secure_computing_mode or set_secure_computing_mode?

sunfishcode

sunfishcode commented on Apr 21, 2025

@sunfishcode
Member

Oops yes, set_secure_computing_mode.

rusty-snake

rusty-snake commented on Apr 21, 2025

@rusty-snake
ContributorAuthor

So basically we deprecate set_secure_computing_mode and add set_secure_computing_mode_strict() and set_secure_computing_mode_filter(filter, flags).

sunfishcode

sunfishcode commented on Apr 21, 2025

@sunfishcode
Member

Yeah, that sounds reasonable. It is less convenient if users want to change the mode dynamically, but that seems unlikely to be common.

linked a pull request that will close this issue on May 1, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      Participants

      @sunfishcode@rusty-snake

      Issue actions

        `set_secure_computing_mode(SecureComputingMode::Filter)` has no filter argument · Issue #1451 · bytecodealliance/rustix