Re: [OE-core] [PATCH] file: explicitly disable seccomp

["Richard Purdie" <richard.purdie@linuxfoundation.org>]

On Fri, 2020-04-03 at 07:23 -0700, Khem Raj wrote:
> On Fri, Apr 3, 2020 at 6:36 AM Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > On Tue, 2020-03-31 at 12:57 +0200, Jan Luebbe wrote:
> > > Hi,
> > > 
> > > On Mon, 2020-01-20 at 17:10 +0000, Ross Burton wrote:
> > > > On 20/01/2020 15:45, Khem Raj wrote:
> > > > > pseudo needs some love since it alters syscalls which go out of
> > > > > bounds
> > > > > what is allowed by libseccomp until then pin your file version to
> > > > > 5.37
> > > > > in arch till a supported distro is affected by same problem. It
> > > > > wont
> > > > > be long better option is to fix pseudo
> > > > 
> > > > That's not quite right.  pseudo LD_PRELOADs itself into file, and
> > > > makes
> > > > syscalls which are not whitelisted in file's seccomp configuration.
> > > > 
> > > > There's nothing pseudo can do to solve this.
> > > 
> > > I stumbled across this thread when checking why libseccomp is not in
> > > oe-core or meta-oe. It seems to me that pseudo could intercept the
> > > seccomp(2) or libseccomps seccomp_* function calls and report them as
> > > unsupported to simulate running on a kernel without seccomp support.
> > > 
> > > What am I missing? :)
> > 
> > I made a guess at a patch:
> > 
> > http://git.yoctoproject.org/cgit.cgi/poky-contrib/commit/?h=rpurdie/t222&id=d675ff53d3ccbc6bd7db5f067d331bf3f94de5cd
> > 
> > Just need someone with a system that can test it now!
> > 
> 
> seems pseudo still has same issue with archlinux latest file
> (file-5.38-3) utility
> 
> Command '['file', '-b',
> '/mnt/b/yoe/build/tmp/work/aarch64-yoe-linux/glibc/2.31+gitAUTOINC+71f2b249a2-r0/package/lib/libnss_db-2.31.so']'
> died with <Signals.SIGSYS: 31>.: Traceback (most recent call last):
>   File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oe/utils.py",
> line 280, in run
>     ret = self._target(*self._args, **self._kwargs)
>   File "/mnt/b/yoe/sources/openembedded-core/meta/lib/oe/package.py",
> line 74, in is_elf
>     result = subprocess.check_output(["file", "-b", path],
> stderr=subprocess.STDOUT).decode("utf-8")
>   File "/usr/lib/python3.8/subprocess.py", line 411, in check_output
>     return run(*popenargs, stdout=PIPE, timeout=timeout, check=True,
>   File "/usr/lib/python3.8/subprocess.py", line 512, in run
>     raise CalledProcessError(retcode, process.args,

There is a pretty horrendous hack in master-next which avoids this (I
think). I went through the following:

a) Disabling seccomp syscall. It falls back to prctl().

b) Disabling prctl() (which is variadac) means file exits with an
error, seccomp must be enabled.

c) Return success but do nothing (don't load the seccomp program)

It appears that returning success works.

Not convinced we want to do that mind...

Cheers,

Richard