Helmut Grohne wrote... [ Disable seccomp if LD_PRELOAD is set ]
> It may be broad, but we used to live without this security feature and
> the approach should reliably fix the regressions.
However, once we (as in Debian) promote seccomp, users will assume it's
available. Silently disabling it in in a way not obvious at all ... for
me it's like disabling the security belt in a car as soon as traffic
uses the left side of the street.
>> * Have a second file package without seccomp support
>
> Please excuse my bluntness. This approach is wrong. Any security that
> requires attention from the user is bad security. If each and every user
> needs to figure out to install file-buildd when they use file with
> LD_PRELOAD, this has a very bad cost/benefit ratio.
Possibly there was a misunderstanding here: Since all the problems that
had arisen with seccomp support in file arose in the context of
packaging building (but see below), my idea was to disable seccomp in
the build proccess globally without creating side-effects like your
LD_PRELOAD approach does. Regular users should better not even know
about the existence of such a package.
>> * Have a build system detection in file(1)
>
> This is only partially solving the problem. In essence, this approach is
> whack-a-mole.
Err, it's just a refinement of your approach "Disable seccomp if
LD_PRELOAD is set".
>> So the final solution I can think of is a distinct environment variable
>> set by debhelper I could depend on.
>
> The actual issue that made me file this bug was autoconf, not debhelper.
Other issues were in debhelper and dh-strip-nondeterminism. I'd like to
catch that as well.
> Can I propose a third solution?
>
> Confine less code. (...)
> Of course, getting there is essentially rewriting the seccomp feature in
> file. You cannot easily bolt it onto file in the way it currently is.
I have to admit this solution is much saner then anything else. There
are some gotchas wrt compression but it should be possible to deal with
them, I'll do some research and take the idea to upstream.
And with another issue (syscall whitelist incomplete on arm64, #932947)
I think it's about time to end this experiment. It was insightful in
many ways but the result is file's seccomp support in its current state
is causing too many side-effects. The next upload in a few hours will
disable seccomp, and a new, saner attempt will hopefully follow soon.
Christoph
signature.asc
Description: PGP signature
