Bug 713710 – sys-apps/file: Add USE=seccomp for non-live ebuilds

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Sam James 2020-03-20 21:45:07 UTC]

Since around 5.38 [0], support has improved quite a bit [1]. 

Can we at least expose the USE flag in non-live ebuilds? (although ideally default eventually).

[0] https://mailman.astron.com/pipermail/file/2019-July/000175.html
[1] https://mailman.astron.com/pipermail/file/2019-July/000175.html

[Comment 1 Sam James 2020-03-20 21:46:14 UTC]

seccomp is particularly apt here given file is often used on untrusted file. 

IIRC OpenBSD implemented a sandboxed/privseped file, that may be worth an investigation too.

[Comment 2 Lars Wendler (Polynomial-C) (RETIRED) 2020-03-20 22:38:10 UTC]

Have you even tried the live ebuild with USE="seccomp"? If yes you'd have noticed that compilation fails:


make[2]: Entering directory '/var/tmp/portage/sys-apps/file-9999/work/file-9999-abi_x86_64.amd64/magic'
../src/file -C -m magic
make[2]: *** [Makefile:828: magic.mgc] Bad system call
make[2]: Leaving directory '/var/tmp/portage/sys-apps/file-9999/work/file-9999-abi_x86_64.amd64/magic'
make[1]: *** [Makefile:458: all-recursive] Error 1
make[1]: Leaving directory '/var/tmp/portage/sys-apps/file-9999/work/file-9999-abi_x86_64.amd64'
make: *** [Makefile:367: all] Error 2


So unless we get this issue fixed, non-live ebuild will only get the USE flag if being p.use.mask-ed.

[Comment 3 Sam James 2020-03-20 23:08:03 UTC]

(In reply to Lars Wendler (Polynomial-C) from comment #2)
> Have you even tried the live ebuild with USE="seccomp"? If yes you'd have
> noticed that compilation fails:
> 

Sure, that's the aim here - figure out what the blockers are, and work through them.
If it all worked, there'd be no fun.

My build of file-5.38 dies in the same place:
>Making all in magic
>make[2]: Entering directory '/var/tmp/portage/sys-apps/file-5.38/work/file-5.38-abi_x86_64.amd64/magic'
>../src/file -C -m magic
>make[2]: *** [Makefile:828: magic.mgc] Bad system call
>make[2]: Leaving directory '/var/tmp/portage/sys-apps/file-5.38/work/file-5.38-abi_x86_64.amd64/magic'
>make[1]: *** [Makefile:400: all-recursive] Error 1
>make[1]: Leaving directory '/var/tmp/portage/sys-apps/file-5.38/work/file-5.38-abi_x86_64.amd64'
>make: *** [Makefile:332: all] Error 2

Works fine w/o sandbox:
>$ ../src/file -C -m magic [runs fine]
and
>$ sandbox ../src/file -C -m magic
>Sandboxed process killed by signal: Bad system call
>Bad system call (core dumped)

[Comment 4 Sam James 2020-03-21 00:10:20 UTC]

From my investigation so far, it seems this is the situation:
* sandbox needs more permissions than file (as you'd expect)
* file requests these
* sandbox uses something extra in its duties, gets killed.

The binary produced works fine to create the magic file outside of the sandbox or with the sandbox on and seccomp disabled with the -S flag.

Rather than patch seccomp.c to include the (likely far excessive) powers sandbox needs, one fix is to just patch the Makefile to call file with -S during the compile process.

I'll do more research and see if I run into any issues.

[Comment 5 Larry the Git Cow 2020-06-15 08:09:19 UTC]

The bug has been closed via the following commit(s):

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=6da8c8078434cfa0e3ec7334de28b27467a0a0b5

commit 6da8c8078434cfa0e3ec7334de28b27467a0a0b5
Author:     Lars Wendler <[e-mail]>
AuthorDate: 2020-06-15 08:02:37 +0000
Commit:     Lars Wendler <[e-mail]>
CommitDate: 2020-06-15 08:09:14 +0000

    sys-apps/file: Bump to version 5.39
    
    Closes: https://bugs.gentoo.org/713710
    Package-Manager: Portage-2.3.101, Repoman-2.3.22
    Signed-off-by: Lars Wendler <[e-mail]>

 sys-apps/file/Manifest                             |   1 +
 sys-apps/file/file-5.39.ebuild                     | 140 +++++++++++++++++++++
 .../file/files/file-5.39-seccomp_sandbox.patch     |  13 ++
 3 files changed, 154 insertions(+)

[Comment 6 Bob Deblier 2021-04-22 07:45:23 UTC]

Bug seems to have resurfaced, in file-5.40-r1.