If you want to use seccomp, the reality is that you need control over all of the code running in your application. If you dynamically link to external code that's updated separately, your usage of seccomp can't really be correct.
-
-
The needed system calls will vary across platforms where it runs due to internal differences in the libraries so there's pain involved in determining what it needs and then it's fragile and can break with any external library updates.
2 replies 0 retweets 0 likes -
Replying to @CopperheadOS @musllibc
Let the application developers profile their app, provide meaningful seccomp profiles in the architectures they support. Glibc taking a stab at seccomp and suggesting updating man pages to indicate the "fragility" of the model is seriously a step back. It's tunnel vision.
1 reply 0 retweets 1 like -
Unfortunately, the glibc developer is correct. If the application didn't ship the code but rather dynamically links against it, it's not correct to make assumptions about system calls and paths it needs to use.
1 reply 1 retweet 2 likes -
It's not a problem limited to glibc either. This is for every dynamically linked library. Statically linking every library solves the problem. Trying to define a stable seccomp ABI for libraries is just not very realistic.
1 reply 1 retweet 1 like -
The main issue for glibc is that they don't properly support static linking, thus suggesting
@musllibc earlier in this thread as a way for an application to be shipped as a self-contained piece of code other than the kernel.1 reply 0 retweets 2 likes -
Not aware of any library making any kind of commitment about system calls that are used and don't think it'd be a very good idea to try doing it. Those libraries also depend on how the C standard library or their own other library dependencies work internally.
1 reply 0 retweets 0 likes -
A library would need to list every C standard library API, etc. used by each call and then glibc would need to make a stability commitment to which system calls can be used by each API. Doubt policies would be made via exhaustively reading documentation anyway...
1 reply 0 retweets 0 likes -
So, not sure how that would solve the problem, since committing to only calling mmap and gettid for an API doesn't prevent an application from not whitelisting gettid if it's not actually being used yet, etc. It's the wrong problem to try solving...
2 replies 0 retweets 0 likes -
The problem is sometimes you realize the implementation has a bug (eg due to kernel limitation) you can fix with extra syscalls...
1 reply 0 retweets 2 likes
For example, https://git.musl-libc.org/cgit/musl/commit?id=0bed7e0acfd34e3fb63ca0e4d99b7592571355a9 …
-
-
Replying to @RichFelker @CopperheadOS and
I think glibc still has this bug, and with the proposed ABI policy it would become impossible to fix.
0 replies 0 retweets 0 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.