make it compile on musl

[wolfv]

Unfortunately, the rseq syscall integer is not yet exposed properly by the libc crate. I opened a PR over there, but in the meantime we could also add the values here, hard-coded:

rust-lang/libc#4028

lmk what you think!

[CLAassistant]

All committers have signed the CLA.

[kylewillmon]

The #[cfg] guard is all that is needed to make the code compile on musl. The hard-coded values are only necessary if the rseq syscall is actually being used by a sandboxed process.

Would it be good enough for your usage to only add the #[cfg] guard for now and then remove it once the libc PR is merged?

[wolfv]

@kylewillmon there are a few more constants missing from libc / musl -- you can find the failing linux builds here: https://github.com/conda/rattler/actions/runs/11798817835

I don't know how security relevant these items are. I am working on a script to make sure that the values in libc are up-to-date.

[kylewillmon]

@wolfv The builds you reference seem to be passing for x86_64 and aarch64, which are the only architectures supported by seccompiler. Adding support for new architectures would require a larger effort.

[wolfv]

Would it be possible to make this an optional feature on these other architectures?

[cd-work]

I don't know how security relevant these items are.

Just to be clear on this: The syscall table is whitelist based, so there is no negative impact on security by not having a syscall in the list. The only impact is that a syscall not in the list will be blocked. That's assuming no new IDs are added of course.

[kylewillmon]

Would it be possible to make this an optional feature on these other architectures?

I think it's possible with a simple patch. You are welcome to give this a try in your fork:

Patch to disable seccomp on other architectures

From e8d953b4f94bc25b0a0fc616ff60c0c5735d4e3f Mon Sep 17 00:00:00 2001
From: Kyle Willmon <[email protected]>
Date: Tue, 12 Nov 2024 09:56:59 -0600
Subject: [PATCH] Allow compilation on other Linux architectures

This patch simply removes the use of seccomp on unsupported
architectures. That should allow compilation and usage with reduced
security, but I have not tested on any of these architectures.
---
 src/linux/mod.rs | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/src/linux/mod.rs b/src/linux/mod.rs
index 1ea105d..8aa66b8 100644
--- a/src/linux/mod.rs
+++ b/src/linux/mod.rs
@@ -13,10 +13,12 @@ use rustix::process::{Gid, Pid, Uid, WaitOptions};

 use crate::error::{Error, Result};
 use crate::linux::namespaces::{MountAttrFlags, Namespaces};
+#[cfg(any(target_arch = "x86_64", target_arch = "aarch64"))]
 use crate::linux::seccomp::SyscallFilter;
 use crate::{Child, Command, Exception, Sandbox};

 mod namespaces;
+#[cfg(any(target_arch = "x86_64", target_arch = "aarch64"))]
 mod seccomp;

 /// Linux sandboxing.
@@ -206,6 +208,7 @@ fn sandbox_init_inner(mut init_arg: ProcessInitArg) -> io::Result<libc::c_int> {
     )?;

     // Setup system call filters.
+    #[cfg(any(target_arch = "x86_64", target_arch = "aarch64"))]
     SyscallFilter::apply().map_err(|err| IoError::new(IoErrorKind::Other, err))?;

     // Block suid/sgid.

But I'm not sure that's the best approach in general. Disabling seccomp reduces the security of the sandbox. Adding support for these architectures in seccompiler would be preferred.

I am also unable to test on any of these architectures, which limits our ability to support them.

[wolfv]

I am sure you can test x86_64-musl?

[cd-work]

I am sure you can test x86_64-musl?

Just to be clear, x86_64-musl is not the problematic one. It's just that if you want all your architectures to be supported, that includes some which aren't supported by seccompiler.

[wolfv]

Sure, but right now birdcage does not compile for x86-64-musl (https://github.com/conda/rattler/actions/runs/11781375294/job/32814109383)

[cd-work]

If the goal is solely about musl, you can just follow the suggestion made in @kylewillmon's original comment.

[wolfv]

I'm happy to to that - I'm just not sure what the rseq syscall does, how important it is and why it's whitelisted in the first place. But if you think all applications will run fine without it then of course we can remove it altogether until libc merges the fixes

[cd-work]

I'm just not sure what the rseq syscall does, how important it is and why it's whitelisted in the first place.

The documentation of the rseq syscall can be found here: https://manpages.opensuse.org/Tumbleweed/librseq-devel/rseq.2.en.html

The reason I'm linking to an opensuse page also answers the question on how important it is: It's not. Many systems don't even have this syscall available, so not having it shouldn't have a big impact on application functionality. There's no glibc wrapper and that's also likely why libc doesn't have it yet.

As far as why it's whitelisted: All system calls that should have no impact on system security are whitelisted by default. This includes every syscall available at the point of writing the list, which included rseq.