That's SELinux's fault? The distributions? The engineers's? At what point would glibc admit that syscall is not just an implementation detail all things (security) considered? I fail to see a positive statement that would move things forward.
-
-
It's the fault of the development model used by the distributions. It's not compatible with holistic security measures requiring control over a well-defined base system. See the other tweets in the main thread.
1 reply 0 retweets 1 like -
CopperheadOS Retweeted CopperheadOS
CopperheadOS added,
CopperheadOS @CopperheadOSHaving great SELinux policies requires control over the whole system. It's fantastic for an OS where the base system and policies are developed together and everything from third parties runs in well-defined sandboxes. It works better if it can be specialized for hardware too.Show this thread1 reply 0 retweets 0 likes -
CopperheadOS Retweeted CopperheadOS
CopperheadOS added,
CopperheadOS @CopperheadOSGoogle develops Android's SELinux policies as part of the OS. Each device extends the policies to support the drivers. Even with the same driver on two devices, it'll probably need a different ioctl whitelist. Nexus and Pixel devices have incredibly restrictive SELinux policies.Show this thread1 reply 0 retweets 1 like -
glibc deciding that internal system calls used by initialization and other APIs are not an implementation detail would resolve the seccomp issues for application with no dynamically linked libraries other than glibc. That's not usually the case.
1 reply 0 retweets 0 likes -
For stuff like landlock, glibc and each other dynamically linked library would need to make commitments about paths too. At the moment, applications can't depend on the system calls and paths accessed by external dependencies not changing.
1 reply 0 retweets 0 likes -
The whole idea behind seccomp / landlock is that applications know what they need to be permitted but that's not the case when they have external dependencies. They only know what the version of the library they tested requires.
1 reply 0 retweets 1 like -
If they dynamically link a library like SQLite with a stable ABI they could similarly break if SQLite adds system calls, etc. Internal system calls, etc. has never been part of the ABI guarantees provided by libraries and it's not very reasonable to expect it.
1 reply 0 retweets 0 likes -
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.
2 replies 0 retweets 0 likes -
I disagree. You just need to make your seccomp whitelist broad & cover all syscalls that are semantically allowed rather than tailoring to an strace.
1 reply 0 retweets 1 like
glibc has very good reasons for not considering which syscalls it uses part of ABI. musl is same except that static linking works well.
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.