| Summary: | app-misc/pax-utils: allow runtime disabling of seccomp | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Sam James <sam> |
| Component: | Current packages | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
| Status: | CONFIRMED --- | ||
| Severity: | normal | CC: | flow, ionen, mgorny |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 713688, 811462 | ||
(In reply to Sam James from comment #0) > sys-apps/file has -S: > ``` > -S, --no-sandbox > [...] > We should probably have a similar option for usage within Portage. ... usage of pax-utils' scanelf, that is. I'd go even further and unless somebody can provide a reasonably real attack scenario against scanelf, I'd remove seccomp and other fancy sandboxing features entirely. It seems like an extreme case of featurism for the sake of pseudo-security. seccomp cause lots of crash on musl, because some basic function like malloc/free/printf in musl is implemented using different syscall than glibc. https://bugs.gentoo.org/783459 Now I find that madvise is not in the allow list but used in free() of musl, and cause scanelf crash again. (In reply to 12101111 from comment #3) > seccomp cause lots of crash on musl, because some basic function like > malloc/free/printf in musl is implemented using different syscall than glibc. > > https://bugs.gentoo.org/783459 > > Now I find that madvise is not in the allow list but used in free() of musl, > and cause scanelf crash again. Please file a new bug for this. pax-utils don't execute external programs, so i don't think the file argument applies (ignoring textrel debugging, but we already handle that) scanelf & lddtree is run on gnarly/untrusted files as part of analysis pipelines. seccomp filtering helps keep that in check. i guess i could rewrite the tool in safe rust. (In reply to SpanKY from comment #5) > pax-utils don't execute external programs, so i don't think the file > argument applies (ignoring textrel debugging, but we already handle that) > > scanelf & lddtree is run on gnarly/untrusted files as part of analysis > pipelines. seccomp filtering helps keep that in check. > > i guess i could rewrite the tool in safe rust. I'm open to alternatives if you can think of any. The problem I'm interested in solving is: the syscall filter often becomes stale compared to new glibc internals and it's led to a bunch of issues when it crashes. We rely on scanelf being available to generate a bunch of VDB metadata. How can we avoid the crashing in Portage? It seems to me like the best way is to just disable seccomp there given if we're merging untrusted binaries, pax-utils is a rather round about way of them getting to do something nasty to the system anyway. (In reply to Sam James from comment #6) the fact that portage is invoking tools and not checking their exit status sounds like a much bigger issue here. pax-utils, like any tool, has had bugs unrelated to seccomp that caused it to crash. were portage to be validating things, it would take it from "system is corrupted until it's too late" to "system is safe, but installing an updated package requires manual intervention". (In reply to SpanKY from comment #7) > (In reply to Sam James from comment #6) > > the fact that portage is invoking tools and not checking their exit status > sounds like a much bigger issue here. pax-utils, like any tool, has had > bugs unrelated to seccomp that caused it to crash. were portage to be > validating things, it would take it from "system is corrupted until it's too > late" to "system is safe, but installing an updated package requires manual > intervention". Yeah, this is what I've ended up implementing: https://bugs.gentoo.org/811462#c11. The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=0f4f85ee3c19ff3acbcf724bf49a52db0766c7a5 commit 0f4f85ee3c19ff3acbcf724bf49a52db0766c7a5 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-31 14:40:47 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-31 14:45:35 +0000 bin: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. Things can go catastrophically wrong if file misses valid input, as we may have invalid VDB metadata. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> NEWS | 16 +++++++++++++--- bin/estrip | 2 +- bin/install-qa-check.d/10ignored-flags | 2 +- bin/misc-functions.sh | 2 +- 4 files changed, 16 insertions(+), 6 deletions(-) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=45c610a03a0686bb89dbea1f45018aa1cd034612 commit 45c610a03a0686bb89dbea1f45018aa1cd034612 Author: Sam James <sam@gentoo.org> AuthorDate: 2022-12-31 14:52:18 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-12-31 14:53:20 +0000 profiles/base: mask sys-apps/pax-utils[seccomp] As noted in mask message, this is far too risky for new libcs/newer versions of libc/sandbox changes and it leads to Portage generating invalid metadata. Portage does warn on it right now though, at least. Bug: https://bugs.gentoo.org/815877 Signed-off-by: Sam James <sam@gentoo.org> profiles/base/package.use.mask | 5 +++++ 1 file changed, 5 insertions(+) The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=c5d40af3c56436cdbf774707cb36a8cdc832b3dd commit c5d40af3c56436cdbf774707cb36a8cdc832b3dd Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-03 04:02:24 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-05 00:33:06 +0000 unpacker.eclass: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. With e.g. new libc or sandbox version (or any number of things...), the syscalls used by file can change which leads to its seccomp filter killing the process. This is an acceptable tradeoff when users are calling file(1), but it makes less sense with trusted input within Portage, especially where it may lead to confusing errors (swallowed within pipes, subshells, etc). Indeed, it might even be the case that file(1) is broken, but the user needs to complete a world upgrade to get a newer file/portage/???, but can't because of various ebuilds (like ones using this eclass) failing. Disable seccomp for these calls to keep working. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> eclass/unpacker.eclass | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=592c4558b9be2f82969ceec835240ebec23ac932 commit 592c4558b9be2f82969ceec835240ebec23ac932 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-03 04:02:04 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-05 00:33:06 +0000 mono.eclass: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. With e.g. new libc or sandbox version (or any number of things...), the syscalls used by file can change which leads to its seccomp filter killing the process. This is an acceptable tradeoff when users are calling file(1), but it makes less sense with trusted input within Portage, especially where it may lead to confusing errors (swallowed within pipes, subshells, etc). Indeed, it might even be the case that file(1) is broken, but the user needs to complete a world upgrade to get a newer file/portage/???, but can't because of various ebuilds (like ones using this eclass) failing. Disable seccomp for these calls to keep working. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> eclass/mono.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=4a52eaeab3ca96b55c45d774dac60d004db8bb39 commit 4a52eaeab3ca96b55c45d774dac60d004db8bb39 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-01-03 03:59:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-01-05 00:33:06 +0000 dotnet.eclass: pass -S to file to disable seccomp Files being installed by Portage are generally trusted but also the syscalls allowed by file are quite broad anyway. With e.g. new libc or sandbox version (or any number of things...), the syscalls used by file can change which leads to its seccomp filter killing the process. This is an acceptable tradeoff when users are calling file(1), but it makes less sense with trusted input within Portage, especially where it may lead to confusing errors (swallowed within pipes, subshells, etc). Indeed, it might even be the case that file(1) is broken, but the user needs to complete a world upgrade to get a newer file/portage/???, but can't because of various ebuilds (like ones using this eclass) failing. Disable seccomp for these calls to keep working. Bug: https://bugs.gentoo.org/811462 Bug: https://bugs.gentoo.org/815877 Bug: https://bugs.gentoo.org/889046 Signed-off-by: Sam James <sam@gentoo.org> eclass/dotnet.eclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) |
sys-apps/file has -S: ``` -S, --no-sandbox On systems where libseccomp (https://github.com/seccomp/libseccomp) is available, the -S option disables sandboxing which is enabled by default. This option is needed for file to execute external decompressing programs, i.e. when the -z option is specified and the built-in decompressors are not available. On systems where sandboxing is not available, this option has no effect. ``` We should probably have a similar option for usage within Portage. (A compromise would be that Portage tried on a known-safe binary and if *that* failed, we fall back to no seccomp with the real stuff we want to analyse.)