Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 815877 - app-misc/pax-utils: allow runtime disabling of seccomp
Summary: app-misc/pax-utils: allow runtime disabling of seccomp
Status: CONFIRMED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Gentoo Toolchain Maintainers
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: seccomp 811462
  Show dependency tree
 
Reported: 2021-10-03 04:23 UTC by Sam James
Modified: 2023-01-05 00:33 UTC (History)
3 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-03 04:23:32 UTC
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.)
Comment 1 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-03 04:29:19 UTC
(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.
Comment 2 Michał Górny archtester Gentoo Infrastructure gentoo-dev Security 2021-10-04 14:24:59 UTC
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.
Comment 3 12101111 2021-10-05 09:28:34 UTC
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.
Comment 4 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-05 18:02:17 UTC
(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.
Comment 5 SpanKY gentoo-dev 2021-10-07 06:58:33 UTC
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.
Comment 6 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2021-10-07 07:04:13 UTC
(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.
Comment 7 SpanKY gentoo-dev 2021-10-07 07:16:43 UTC
(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".
Comment 8 Sam James archtester Gentoo Infrastructure gentoo-dev Security 2022-04-15 09:24:10 UTC
(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.
Comment 9 Larry the Git Cow gentoo-dev 2022-12-31 14:48:12 UTC
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(-)
Comment 10 Larry the Git Cow gentoo-dev 2022-12-31 14:53:25 UTC
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(+)
Comment 11 Larry the Git Cow gentoo-dev 2023-01-05 00:33:43 UTC
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(-)