Author image Ryan Voots
and 1 contributors

NAME

Sys::Linux::Syscall::Execve - A raw execve() wrapper that preserves memory addresses

DESCRIPTION

Due to changes in how exec() works in the upcoming 5.28 to fix [perl #129888] I can no longer expect exec() to preserve the memory address of the arguments provided to it.

Why this weird requirement? It's because I need to preserve that address in order to setup an eBPF program with Seccomp that restricts what can be executed inside a sandbox.

SHOULD I USE THIS

No. Perl's built in exec() is better for every use case that you'll ever have. Not only is it portable, it handles many more edge cases than you can ever expect this to acknowledge even exist.

This is only if you need to restrict the execve() syscall in a Seccomp sandbox. There are no other possible uses for this.

EXPORT_OK

execve

A simple recreation of perl's exec() but using our internal code to execute everything. However it will never invoke a shell automatically. This will pass %ENV to the executed program.

execve_env
    execve_env("/path/to/cmd", [arg1, arg2, arg3, ...], {env_var => value, ...});

Lets you setup a custom environment to be passed to the new program. Useful for sanatizing everything for the new program.

execve_byref
    my $cmd = "/path/to/cmd";
    my $args = [$cmd, arg1, arg2, arg3, ...];
    my $env = {env_var => value, ...};

    execve_byref(\$cmd, $args, $env);

This is a special interface, passing the command in as a scalar ref helps ensure that the correct string gets passed by pointer to execve() at the final stage. This is necessary to be perfectly sure that the correct value is passed to the syscall. It's important to note that this method requires you to set the command as the first argument. This gets used to set the running name of the program and may allow you to unlock other behavior in it based on this value (e.g. busybox).

TODO

Enable getting the address of arguments and environment variables to be passed also, for extra paranoia

SEE ALSO

App::EvalServerAdvanced

AUTHOR

Ryan Voots <simcop@cpan.org>