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: 2022-04-15 09:24 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.