Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

sandbox.c causes compilation failure on Linux in some cases #4

Closed
mxkrsv opened this issue Jul 1, 2021 · 10 comments
Closed

sandbox.c causes compilation failure on Linux in some cases #4

mxkrsv opened this issue Jul 1, 2021 · 10 comments

Comments

@mxkrsv
Copy link

mxkrsv commented Jul 1, 2021

On musl libc on archs different from x86_64 and aarch64 sandbox.c causes errors when compiling, probably due to musl not having proper implementation of __NR functions for them. Having a build-time option to disable sandboxing would be nice.

@omar-polo
Copy link
Owner

Yes, sorry for that; I've only tested on amd64 and aarch64 so far. Adding a build-time option to disable sandboxing would indeed be easy, but I would prefer to have it working whenever possible.

I'll try to build on x86 to hopefully fix that (from the failure it seems that on x86 the actual syscalls are different).

@mxkrsv
Copy link
Author

mxkrsv commented Jul 2, 2021

Thanks. On some arches it fails because of missing SECCOMP_AUDIT_ARCH defines. I found the most complete (and the most boilerplate) solution which contains all Alpine's arches here.

omar-polo added a commit that referenced this issue Jul 2, 2021
* SECCOMP_AUDIT_ARCH extended to support more architectures
* relax fcntl policy: allow the syscall regardless of the flags
* wrap every syscall in a ifdef, and add some (statx, fcntl64, ...)
  used in x86

Some bits were taken from dhcpcd[0], thanks!

#4 related


[0]: https://roy.marples.name/git/dhcpcd/blob/HEAD:/src/privsep-linux.c
omar-polo added a commit that referenced this issue Jul 2, 2021
Calling `configure' with --disable-sandbox will disable the sandbox
support *completely* at compile time.  gmid will still complain at
compile time and during the startup.

Users shouldn't disable the sandbox if possible, but instead report
problem upstream so they get fixed (hopefully.)

#4 related
@omar-polo
Copy link
Owner

I updated the seccomp filter and added a --disable-sandbox flag for the configure script (that I dislike so it isn't advertised anywhere, but if it's necessary, it's there)

Thanks for liking that bit from dhcpcd, it was really helpful! :)

make regress now passes on alpine x86 and amd64, and on void aarch64 too, so hopefully I haven't screwed anything. 137def5 and 8bb8cf2 should apply cleanly on top of the 1.6.1 but I can tag a 1.6.2 if it's easier for you, just let me know.

@mxkrsv
Copy link
Author

mxkrsv commented Jul 2, 2021

Thanks, now it compiles on all architectures (except riscv64, no gitlab runner to test yet) even without --disable-sandbox. However, patch complains about ChangeLog in 137def5, so tagging would be cleaner.

@omar-polo
Copy link
Owner

I haven't thought about the ChangeLog file, sorry! I tagged the 1.6.2: it's the 1.6.1 with 137def5 and 8bb8cf2 on top.

I'm not familiar with how alpine infrastructure works, so I hope you'd excuse this probably stupid question, but the regression suite (make regress) is ran too as as part of building a package?

Thanks for testing!

@mxkrsv
Copy link
Author

mxkrsv commented Jul 3, 2021

Yes, make regress is done in check(). It passes on all architectures except ppc64le, where it hangs on ./runtime somewhy.

@omar-polo
Copy link
Owner

Thanks for the clarification! :)

The hangs smell like a possible seccomp failure (where the daemon got killed but the client is still waiting for the reply), even though one hour of wait is still probably a bit too much. I'm going to emulate a ppc64 and see what's going on.

(also adding a timeout to the regress suite wouldn't harm, sorry for hanging your builds!)

@mxkrsv
Copy link
Author

mxkrsv commented Jul 3, 2021

Thanks for efforts

omar-polo added a commit that referenced this issue Jul 3, 2021
before we matched ppc64le as ppc64 (which is big ending I presume), so
the seccomp filter would always kill gmid

#4 related
@omar-polo
Copy link
Owner

No efforts at all -- I got to play with (virtualized) ppc64 :D

The problem was that ppc64le was matched as ppc64 (big endian). The seccomp filter would then presume that the current architecture is not the one the program was built on and so disallow any syscall. It should be fixed as of b24021d, on my vm make regress passes 🎉

@mxkrsv
Copy link
Author

mxkrsv commented Jul 3, 2021

Thanks, with this patch it works perfectly. Alpine package will probably be merged soon.

@mxkrsv mxkrsv closed this as completed Jul 3, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants