file(1) now with seccomp support enabled

classic Classic list List threaded Threaded
27 messages Options
12
Reply | Threaded
Open this post in threaded view
|

file(1) now with seccomp support enabled

debian-devel
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

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Russ Allbery-2
Christoph Biedl <[hidden email]> writes:

> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.

Thank you very much for doing this!  Here's hoping this sets a trend.  It
will provide so much defense in depth against malicious files.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Paul Gevers-4
In reply to this post by debian-devel
Hi Christoph,

On 19-07-2019 17:18, Christoph Biedl wrote:
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.

This probably warrants an entry in the bullseye release-notes. Should we
already forward your original mail to the BTS for that, or do you care
to provide better text once you learn better what breaks (and what not)?

Paul


signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Christoph Biedl-7
Paul Gevers wrote...

> Hi Christoph,
>
> On 19-07-2019 17:18, Christoph Biedl wrote:
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> This probably warrants an entry in the bullseye release-notes. Should we
> already forward your original mail to the BTS for that, or do you care
> to provide better text once you learn better what breaks (and what not)?

For the time being I'd suggest to just take a note somewhere and
re-visit the situation in a year from now. Too many more changes might
come, hopefully for the better. So as of now, writing elaborated texts
about the situation might be wasted time.

    Christoph

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

seccomp woes (was: file(1) now with seccomp support enabled)

Christoph Biedl-7
In reply to this post by Russ Allbery-2
Russ Allbery wrote...

> Christoph Biedl <[hidden email]> writes:
>
> > tl;dr: The file program in unstable is now built with seccomp support
> > enabled, expect breakage in some rather uncommon use cases.
>
> Thank you very much for doing this!  Here's hoping this sets a trend.  It
> will provide so much defense in depth against malicious files.

Thanks for the positive feedback. While I agree seccomp is something
nice to have, I'd like to share two two very different thoughts that
arose while doing this.


The first one is Debian-specific: Declaring build-dependencies on
libaries that are not available in all archs, like seccomp.

This is not at all specific for seccomp, but perhaps it's one of the
places where this problem is seen relatively often. So read "seccomp"
as "$seccomp", describing a library that does not exist in all
architectures.

The build system of the file package uses autoconf to check for
presence of the seccomp library and will just disable that feature if
support is missing. But just adding "libseccomp-dev" will break the
build on e.g. alpha for an unsatisfyable build dependency - I don't
wish to simply ignore that. So I have to make sure lack of seccomp in
these architectures does not break the build.

Solutions I've seen (use codesearch to find examples):

* People don't care
* People add a hard-coded list of archs into the dependency clause
  like "libseccomp-dev [amd64 ...]"

The first I consider plain ignorant.

The second puts work on each package maintainer who uses libseccomp in
the build dependencies: The list of supported archs may change, and
having to maintain this in many places is unrealiable and also stupid
work. Still it does the job - I am just looking for a better way.

Solutions I can think of:

* Centralize the list of supported archs in the seccomp packages. By
  either creating an empty libseccomp-dev for the archs where seccomp
  is not supported, or by creating a "libseccomp-dev-dummy" for these.
  In the latter case package maintainers would have to do a one-time
  change of the build dependency into "libseccomp-dev |
  libseccomp-dev-dummy" and can focus on other issues then.

* Add an always-satisfyable alternative clause, like
  "Build-Depends: libseccomp-dev | base-files".

  Yuck.

* Introduce a statement for relaxed build dependencies. In other words,
  a new "Build-Depends-Try:" or "Build-Recommends:" that will be tried
  to be satisfied, but failure to do so will emit a warning at most.

Honestly, the last one has a lot of charm since it means a one-time
effort only. That effort however is huge and includes convincing
several people to implement it.



The second is questioning whether seccomp is something feasible on the
big scale. The domain of a seccomp filter set is the application, and
the way more and more libraries might be linked in during development,
the more syscalls have to be whitelisted, defeating the idea of
seccomp. So in consequence you'll either create a lot of small programs
or several threads with different sets of whitelisted syscalls. In
either way a lot of IPC is needed which is time-consuming and
error-prone, in implementation, execution, and debugging.

    Christoph

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: seccomp woes (was: file(1) now with seccomp support enabled)

Marco d'Itri
On Jul 20, Christoph Biedl <[hidden email]> wrote:

> * Centralize the list of supported archs in the seccomp packages. By
>   either creating an empty libseccomp-dev for the archs where seccomp
>   is not supported, or by creating a "libseccomp-dev-dummy" for these.
>   In the latter case package maintainers would have to do a one-time
>   change of the build dependency into "libseccomp-dev |
>   libseccomp-dev-dummy" and can focus on other issues then.
I tried this with libsystemd-dummy, which creates a libsystemd-dev
package on hurd and kfreebsd which allows to build unmodifed packages.
The package bit rot long ago and then nobody cared enough to fix it, so
packages which unconditionally depend on libsystemd-dev nowadays just
fail on these architectures.

--
ciao,
Marco

signature.asc (673 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: seccomp woes

Russ Allbery-2
In reply to this post by Christoph Biedl-7
Christoph Biedl <[hidden email]> writes:

> * Centralize the list of supported archs in the seccomp packages. By
>   either creating an empty libseccomp-dev for the archs where seccomp
>   is not supported, or by creating a "libseccomp-dev-dummy" for these.
>   In the latter case package maintainers would have to do a one-time
>   change of the build dependency into "libseccomp-dev |
>   libseccomp-dev-dummy" and can focus on other issues then.

For what it's worth, not being a libseccomp maintainer, I really like this
idea.

> * Introduce a statement for relaxed build dependencies. In other words,
>   a new "Build-Depends-Try:" or "Build-Recommends:" that will be tried
>   to be satisfied, but failure to do so will emit a warning at most.

> Honestly, the last one has a lot of charm since it means a one-time
> effort only. That effort however is huge and includes convincing
> several people to implement it.

It has some irritating build reproducibility issues, although maybe
they're adequately dealt with via build manifests.

> The second is questioning whether seccomp is something feasible on the
> big scale. The domain of a seccomp filter set is the application, and
> the way more and more libraries might be linked in during development,
> the more syscalls have to be whitelisted, defeating the idea of
> seccomp. So in consequence you'll either create a lot of small programs
> or several threads with different sets of whitelisted syscalls. In
> either way a lot of IPC is needed which is time-consuming and
> error-prone, in implementation, execution, and debugging.

Yeah, it's tricky, particularly when one is trying to support general
applications.  I think the best case scenario is something like file,
where the scope is pretty limited.

Another pattern that can work is to identify the particularly problematic
bit of code where you think most of the bugs are (often in the parser, for
instance) and try to delegate only that portion to one subprocess,
although that does mean a lot of IPC.  (Particularly since we don't have a
great standard data packing format to pass things back and forth.)

I would love to see more places where seccomp is at least present, if
optional and off by default, since it provides an option to use the
program more securely and accept that it breaks a lot of features.  A
great example would be ghostscript -- I would love to be able to prevent
it from executing programs, writing to arbitrary files, and many other
things that, strictly speaking, are part of the PostScript spec and
therefore upstream wants to support in the more general case.  Everyone
who cares about this already has to pass in -dSAFER, so we're already
dealing with the complexity cost of this being optional.

This is hard and I don't think we have a great ecosystem or set of
libraries or techniques around this yet, but I also think adding these
types of syscall filters has way more security impact per unit time than
tuning compiler options or plowing through fuzzing bugs, since it can
remove whole classes of attacks permanently regardless of future code
errors.

--
Russ Allbery ([hidden email])               <http://www.eyrie.org/~eagle/>

Reply | Threaded
Open this post in threaded view
|

Re: seccomp woes

gregor herrmann-3
In reply to this post by Christoph Biedl-7
On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote:

> * Centralize the list of supported archs in the seccomp packages. By
>   either creating an empty libseccomp-dev for the archs where seccomp
>   is not supported, or by creating a "libseccomp-dev-dummy" for these.
>   In the latter case package maintainers would have to do a one-time
>   change of the build dependency into "libseccomp-dev |
>   libseccomp-dev-dummy" and can focus on other issues then.

AFAIK this won't work because sbuild on the buildds is configured to
only use the first alternative from a list of build dependencies.
 

Cheers,
gregor

--
 .''`.  https://info.comodo.priv.at -- Debian Developer https://www.debian.org
 : :' : OpenPGP fingerprint D1E1 316E 93A7 60A8 104D  85FA BB3A 6801 8649 AA06
 `. `'  Member VIBE!AT & SPI Inc. -- Supporter Free Software Foundation Europe
   `-  

signature.asc (981 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

sbuild: do not fail when there are alternatives

Geert Stappers-2
Package: sbuild


Previous-Subject: Re: seccomp woes
Original-To: [hidden email]

On Fri, Jul 19, 2019 at 11:28:36PM -0300, gregor herrmann wrote:

> On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote:
>
> > * Centralize the list of supported archs in the seccomp packages. By
> >   either creating an empty libseccomp-dev for the archs where seccomp
> >   is not supported, or by creating a "libseccomp-dev-dummy" for these.
> >   In the latter case package maintainers would have to do a one-time
> >   change of the build dependency into "libseccomp-dev |
> >   libseccomp-dev-dummy" and can focus on other issues then.
>
> AFAIK this won't work because sbuild on the buildds is configured to
> only use the first alternative from a list of build dependencies.
Reported as bug.

Not checked if it already was reported before.
Not checked if it really fails when it can't find
the first alternative from list of build dependencies.

Thing is that sbuild _might_ be blocking
a nice way to cope with libraries that are not available
on all architectures.

Context at https://lists.debian.org/debian-devel/2019/07/msg00405.html


Groeten
Geert Stappers
--
Leven en laten leven

signature.asc (836 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sbuild: do not fail when there are alternatives

Johannes Schauer-3
Hi,

Quoting Geert Stappers (2019-07-20 07:50:11)

> On Fri, Jul 19, 2019 at 11:28:36PM -0300, gregor herrmann wrote:
> > On Sat, 20 Jul 2019 00:21:10 +0200, Christoph Biedl wrote:
> >
> > > * Centralize the list of supported archs in the seccomp packages. By
> > >   either creating an empty libseccomp-dev for the archs where seccomp
> > >   is not supported, or by creating a "libseccomp-dev-dummy" for these.
> > >   In the latter case package maintainers would have to do a one-time
> > >   change of the build dependency into "libseccomp-dev |
> > >   libseccomp-dev-dummy" and can focus on other issues then.
> >
> > AFAIK this won't work because sbuild on the buildds is configured to
> > only use the first alternative from a list of build dependencies.
Yes it will work. Please read Christoph's proposal again. There is an "or" in
the second sentence.

A solution that either produces an empty libseccomp-dev package or a
libseccomp-dev-maybe package which either does or doesn't depend on
libseccomp-dev, depending on the architecture will work perfectly fine with
sbuild as it is configured on the buildds.

> Reported as bug.
>
> Not checked if it already was reported before.
> Not checked if it really fails when it can't find
> the first alternative from list of build dependencies.
>
> Thing is that sbuild _might_ be blocking
> a nice way to cope with libraries that are not available
> on all architectures.

No it does not block this. The sbuild configuration variable
$resolve_alternatives or the command line option --resolve-alternatives allows
one to enable or disable that sbuild only uses the first alternative.

As Gregor also correctly wrote, the problem is not sbuild but how sbuild is
configured on the buildds.

You might want to re-assign the bug to the buildd admins if you really want to
propose that the handling of alternatives is changed.

Thanks!

cheers, josch

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: sbuild: do not fail when there are alternatives

Aurelien Jarno
On 2019-07-20 07:58, Johannes Schauer wrote:
> No it does not block this. The sbuild configuration variable
> $resolve_alternatives or the command line option --resolve-alternatives allows
> one to enable or disable that sbuild only uses the first alternative.
>
> As Gregor also correctly wrote, the problem is not sbuild but how sbuild is
> configured on the buildds.

This is indeed something configurable at the wanna-build level.

> You might want to re-assign the bug to the buildd admins if you really want to
> propose that the handling of alternatives is changed.

This is done on purpose in order to provide stable features over time.
If a package build-depends on foo | bar and foo is temporarily
uninstallable (for example due to a transition or a version mismatch
between arch:all and arch:any) bar will be used instead, possibly
disabling some features in the package. In the file & libseccomp
example, it means seccomp support might be silently disabled.

Note that for backports, alternatives are considered, as the above is
very unlikely to happen.

--
Aurelien Jarno                          GPG: 4096R/1DDD8C9B
[hidden email]                 http://www.aurel32.net

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: seccomp woes (was: file(1) now with seccomp support enabled)

smcv
In reply to this post by Christoph Biedl-7
On Sat, 20 Jul 2019 at 00:21:10 +0200, Christoph Biedl wrote:
> The build system of the file package uses autoconf to check for
> presence of the seccomp library and will just disable that feature if
> support is missing. But just adding "libseccomp-dev" will break the
> build on e.g. alpha for an unsatisfyable build dependency - I don't
> wish to simply ignore that. So I have to make sure lack of seccomp in
> these architectures does not break the build.

... unless seccomp is sufficiently important to your dependent package
that you would prefer for your dependent package not to be available
on non-seccomp architectures until seccomp becomes available there.

For file(1) it certainly seems better to consider seccomp to be a
hardening/quality-of-implementation thing and fall back to not having it;
for flatpak I decided it was better to have flatpak remain unavailable
on non-seccomp architectures, because there are some sandbox escapes
that are only prevented by it using seccomp. Both approaches can be valid,
depending on the dependent package.

    smcv

Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled [and 1 more messages]

Ian Jackson-2
In reply to this post by debian-devel
Christoph Biedl writes ("file(1) now with seccomp support enabled"):
> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.

Thanks for this work and for the heads-up.

PS: Did you really mean to send your first mail like thiks
  From: Christoph Biedl <[hidden email]>
?  It seems rather odd :-).

Christoph Biedl writes ("seccomp woes (was: file(1) now with seccomp support enabled)"):
> Solutions I've seen (use codesearch to find examples):
>
> * People don't care
> * People add a hard-coded list of archs into the dependency clause
>   like "libseccomp-dev [amd64 ...]"
>
> The first I consider plain ignorant.

Quite.

> * Centralize the list of supported archs in the seccomp packages. By
>   either creating an empty libseccomp-dev for the archs where seccomp
>   is not supported, or by creating a "libseccomp-dev-dummy" for these.
>   In the latter case package maintainers would have to do a one-time
>   change of the build dependency into "libseccomp-dev |
>   libseccomp-dev-dummy" and can focus on other issues then.

Others have pointed out that for good reasons the buildds insist on
the first alternative.

But maybe we could create a meta package like this

  Package: libseccomp-dev-maybe
  Depends: libseccomp-dev [!unsupported arch list]
  Architecture: all

That would be available and installable on all architectures and you
could depend on that.  It would centralise the unsupported arch list
and could be generated easily by src:libseccomp-dev.

Can anyone see a problem with this idea ?

Ian.

--
Ian Jackson <[hidden email]>   These opinions are my own.

If I emailed you from an address @fyvzl.net or @evade.org.uk, that is
a private address which bypasses my fierce spamfilter.

Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Chris Lamb -2
In reply to this post by debian-devel
[Adding [hidden email] to CC]

Hi Christoph,

> Overall, I'm just asking to keep an eye on possible breakage, also
> check the kernel log.

I noticed that there were a number of recent regressions in previously
reproducible Java packages being tested by the Reproducible Builds
project's CI platform which I could identify as being caused by our
strip-nondeterminism tool.

However, as there was a very recent change to some strip-nondeterminism
code that uses "monkey patching" I was predisposed to believe that was
the cause, but it eventually turned out to be the call to file(1)
missing a --no-sandbox parameter (where supported / appropriate).

It did not even occur to check my kernel log as you suggest — it was
only when quickly hacking in a:

    override_dh_strip_non_determinism:
            strace -eexecve -f dh_strip_nondeterminism

… to my test package that I figured the file(1) process was being
killed (without returning any output) with SIGCHLD that things were
perhaps lower-level in nature. This has been resolved in strip-
nondeterminism 1.3.0, uploaded this afternoon.

This mail is not a request for anything, but rather a general heads-up
for you and a way of "keyword stuffing" various terms the above
paragraphs into search indexes for the benefit of others looking for
perhaps-obscure issue like this in the future. It is also an implicit
thanks for pushing security hardening features. :)


Best wishes,

--
      ,''`.
     : :'  :     Chris Lamb
     `. `'`      [hidden email] 🍥 chris-lamb.co.uk
       `-

Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Christoph Biedl-7
In reply to this post by debian-devel
Christoph Biedl wrote...

> tl;dr: The file program in unstable is now built with seccomp support
> enabled, expect breakage in some rather uncommon use cases.

Several issues popped up in the last days as a result of that change,
and in spite of some band-aiding to current implementation of seccomp in
the file program creates way more trouble than I am willing to ignore.
So, sadly, I've reverted seccomp support for the time being to avoid
further disruption of the bullseye development.

However, Helmut Grohne has suggested to confine only that part of the
code that is most likely susceptible to vulnerabilities, details in
#932762, and I agree this is possibly the better way to go. This
requires co-ordination with upstream and will take a bit of time.

    Christoph

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Vincas Dargis
On 2019-07-26 18:59, Christoph Biedl wrote:
>> tl;dr: The file program in unstable is now built with seccomp support
>> enabled, expect breakage in some rather uncommon use cases.
Interesting, what are these uncommon use cases? Maybe we could confine it with AppArmor instead,
since we have it enabled by default?

Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Christoph Biedl-7
Vincas Dargis wrote...

> On 2019-07-26 18:59, Christoph Biedl wrote:
> > > tl;dr: The file program in unstable is now built with seccomp support
> > > enabled, expect breakage in some rather uncommon use cases.
>
> Interesting, what are these uncommon use cases? Maybe we could confine it
> with AppArmor instead, since we have it enabled by default?

LD_PRELOAD ruins your day. From the kernel's point of view there is no
difference between a syscall coming from the actual application and one
coming from the code hooked into it. And while the syscalls done by the
first (i.e. file) are more or less known, the latter requires
examination of each and every implementation and whitelisting
everything. Eventually fakeroot-tcp, wishes to open sockets, something
I certainly would not want to whitelist.

TTBOMK apparmor would not provide a sane solution for that problem.
There still might be another use case: The file program should[citation
needed] not write to any file. Reading however must be possible for
every item in the entire file system.

    Christoph

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Philipp Kern-2
On 2019-07-27 03:55, Christoph Biedl wrote:

> Vincas Dargis wrote...
>
>> On 2019-07-26 18:59, Christoph Biedl wrote:
>> > > tl;dr: The file program in unstable is now built with seccomp support
>> > > enabled, expect breakage in some rather uncommon use cases.
>>
>> Interesting, what are these uncommon use cases? Maybe we could confine
>> it
>> with AppArmor instead, since we have it enabled by default?
>
> LD_PRELOAD ruins your day. From the kernel's point of view there is no
> difference between a syscall coming from the actual application and one
> coming from the code hooked into it. And while the syscalls done by the
> first (i.e. file) are more or less known, the latter requires
> examination of each and every implementation and whitelisting
> everything. Eventually fakeroot-tcp, wishes to open sockets, something
> I certainly would not want to whitelist.

FWIW the same is true when you just link against libraries and they
change their behavior. That makes things pretty brittle.

That being said: It feels like if you face this situation, you could
also fork off a binary with a clean environment (i.e. without
LD_PRELOAD) and minimal dependencies and only protect that with seccomp.
Of course you lose the integration point of LD_PRELOAD that others might
want to use if you do that, in which case I guess one could offer a flag
to skip that fork.

In terms of prior art SSH also forks off an unprivileged worker to
handle network authentication in preauth and only seccomps that one
rather than its main process. But it's also not doing the environment
cleanup AFAICS.

Kind regards and thanks for making all of us more secure! :)
Philipp Kern

Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Vincas Dargis
In reply to this post by Christoph Biedl-7
On 2019-07-27 04:55, Christoph Biedl wrote:
> Eventually fakeroot-tcp, wishes to open sockets, something
> I certainly would not want to whitelist.

In AppArmor case, "non-standard" use cases can be dealt with by editing
`/etc/apparmor.d/local/usr.bin.foo`, adding any necessary rules (like allowing to mmap() some
specific LD_PRELOAD library if needed for that use case), or by disabling profile completely as
worst case workaround.

> TTBOMK apparmor would not provide a sane solution for that problem.
> There still might be another use case: The file program should[citation
> needed] not write to any file. Reading however must be possible for
> every item in the entire file system.

That's how I imagine AA profile for `file` - reads absolutely everything, and not expecting to
write, unless to some temp file or similar. But as you said, citation needed.

Reply | Threaded
Open this post in threaded view
|

Re: file(1) now with seccomp support enabled

Jakub Wilk-5
In reply to this post by Christoph Biedl-7
* Christoph Biedl <[hidden email]>, 2019-07-27, 03:55:
>The file program should[citation needed] not write to any file

...except when using the -C option.

--
Jakub Wilk

12