Package: release-notes
In order to not forget this. We should check what happened by the time
we release bullseye.
Paul
-------- Forwarded Message --------
Subject: file(1) now with seccomp support enabled
Resent-Date: Fri, 19 Jul 2019 15:25:41 +0000 (UTC)
Resent-From: debian-devel@lists.debian.org
Date: Fri, 19 Jul 2019 17:18:52 +0200
From: Christoph Biedl <debian-devel@lists.debian.org>
To: debian-devel@lists.debian.org
tl;dr: The file program in unstable is now built with seccomp support
enabled, expect breakage in some rather uncommon use cases.
Hello,
Upstream of the file package added seccomp support a while ago, and
probably everyone with even a small concern about security will agree
the file program, often being used on dubious or even doubtless
malicious input, should use seccomp to make the attack surface smaller.
However I refrained from enabling this feature back then just weeks
before the buster freeze, in restrospect: indeed the right decision.
Now this early moment in the bullseye development cycle is a good time,
so there's version 1:5.37-2, accepted in unstable a few moments ago.
This however comes with a price: Some features are no longer available.
For example, inspecting the content of compressed files (disabled by
default, command-line parameters -z and -Z) is now supported for a few
compressions only: gzip (and friends, see libz), bzip2, lzma, xz.
Decompressing other formats requires invocation of external programs
which will lead to a program abort (SIGSYS).
Also, when running in LD_PRELOAD environments, that extra library may
use blacklisted syscalls. One example is fakeroot which caused breakage
in debhelper (#931985, already fixed). In both cases you should see a
log message in the kernel log then.
There is a workaround for such situations which is disabling seccomp,
command line parameter --no-sandbox.
But I have no idea about the impact this will cause. Checking all
packages that (install-)depend on file for usage of these parameters
turned out to be a fairly though job. Probably I've killed
codesearch.d.n a few times, the term "file" is just very generic :)
Some 53 binary packages have a dependency on the file package, two of
them (cloud-utils, cracklib2) are very likely affected and will receive
an extra bug report.
Overall, I'm just asking to keep an eye on possible breakage, also
check the kernel log. If you encounter one and can imagine a better
solution than simply disabling seccomp in that case, let me know via
the BTS.
Finally, a clarification: Applications that link libmagic instead of
calling the file executable are not affected by any of this. But the
respective program authors might consider enabling seccomp on their
own, for the above reason.
Cheers,
Christoph
Attachment:
signature.asc
Description: OpenPGP digital signature