[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#932580: marked as done (Fwd: file(1) now with seccomp support enabled)

Your message dated Wed, 17 Mar 2021 22:10:58 +0100
with message-id <1616015372@msgid.manchmal.in-ulm.de>
and subject line Re: Fwd: file(1) now with seccomp support enabled
has caused the Debian Bug report #932580,
regarding Fwd: file(1) now with seccomp support enabled
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org

932580: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=932580
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: release-notes

In order to not forget this. We should check what happened by the time
we release bullseye.


-------- 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.


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.


Attachment: signature.asc
Description: OpenPGP digital signature

--- End Message ---
--- Begin Message ---
Paul Gevers wrote...

> Ping. Should we indeed add something to the release notes?

Not needed. The seccomp support turned out to be not feasible,
so I reverted it in 1:5.37-5 (July 2019).


Attachment: signature.asc
Description: PGP signature

--- End Message ---

Reply to: