* [PATCH] file: explicitly disable seccomp
@ 2019-10-18 11:28 Ross Burton
2019-10-18 12:33 ` Khem Raj
0 siblings, 1 reply; 13+ messages in thread
From: Ross Burton @ 2019-10-18 11:28 UTC (permalink / raw)
To: openembedded-core
file will automatically enable seccomp if the seccomp headers are available, but
the build will fail on Opensuse Tumbleweed because the include paths are wrong.
Enabling seccomp is a bad idea because it interacts badly with pseudo (causing
build failures), so explicitly and globally disable seccomp.
Signed-off-by: Ross Burton <ross.burton@intel.com>
---
meta/recipes-devtools/file/file_5.37.bb | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/file/file_5.37.bb b/meta/recipes-devtools/file/file_5.37.bb
index a840dbc012b..c53a120b840 100644
--- a/meta/recipes-devtools/file/file_5.37.bb
+++ b/meta/recipes-devtools/file/file_5.37.bb
@@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
inherit autotools update-alternatives
+EXTRA_OECONF += "--disable-libseccomp"
+
ALTERNATIVE_${PN} = "file"
ALTERNATIVE_LINK_NAME[file] = "${bindir}/file"
--
2.20.1
^ permalink raw reply related [flat|nested] 13+ messages in thread
* Re: [PATCH] file: explicitly disable seccomp
2019-10-18 11:28 [PATCH] file: explicitly disable seccomp Ross Burton
@ 2019-10-18 12:33 ` Khem Raj
2019-10-18 21:28 ` Richard Purdie
0 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2019-10-18 12:33 UTC (permalink / raw)
To: Ross Burton; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1412 bytes --]
On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.burton@intel.com> wrote:
> file will automatically enable seccomp if the seccomp headers are
> available, but
> the build will fail on Opensuse Tumbleweed because the include paths are
> wrong.
>
> Enabling seccomp is a bad idea because it interacts badly with pseudo
> (causing
> build failures), so explicitly and globally disable seccomp.
>
> Signed-off-by: Ross Burton <ross.burton@intel.com>
> ---
> meta/recipes-devtools/file/file_5.37.bb | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-devtools/file/file_5.37.bb
> b/meta/recipes-devtools/file/file_5.37.bb
> index a840dbc012b..c53a120b840 100644
> --- a/meta/recipes-devtools/file/file_5.37.bb
> +++ b/meta/recipes-devtools/file/file_5.37.bb
> @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
>
> inherit autotools update-alternatives
>
> +EXTRA_OECONF += "--disable-libseccomp"
> +
On host it makes sense but how about for target recipe ? We do have
libseccomp support
Perhaps it’s best to disable it for native and native sdk alone ?
>
> ALTERNATIVE_${PN} = "file"
> ALTERNATIVE_LINK_NAME[file] = "${bindir}/file"
>
> --
> 2.20.1
>
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
[-- Attachment #2: Type: text/html, Size: 2545 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: explicitly disable seccomp
2019-10-18 12:33 ` Khem Raj
@ 2019-10-18 21:28 ` Richard Purdie
2019-10-19 5:26 ` Khem Raj
2020-01-20 12:53 ` Martin Hundebøll
0 siblings, 2 replies; 13+ messages in thread
From: Richard Purdie @ 2019-10-18 21:28 UTC (permalink / raw)
To: Khem Raj, Ross Burton; +Cc: openembedded-core
On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote:
>
>
> On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.burton@intel.com>
> wrote:
> > file will automatically enable seccomp if the seccomp headers are
> > available, but
> > the build will fail on Opensuse Tumbleweed because the include
> > paths are wrong.
> >
> > Enabling seccomp is a bad idea because it interacts badly with
> > pseudo (causing
> > build failures), so explicitly and globally disable seccomp.
> >
> > Signed-off-by: Ross Burton <ross.burton@intel.com>
> > ---
> > meta/recipes-devtools/file/file_5.37.bb | 2 ++
> > 1 file changed, 2 insertions(+)
> >
> > diff --git a/meta/recipes-devtools/file/file_5.37.bb
> > b/meta/recipes-devtools/file/file_5.37.bb
> > index a840dbc012b..c53a120b840 100644
> > --- a/meta/recipes-devtools/file/file_5.37.bb
> > +++ b/meta/recipes-devtools/file/file_5.37.bb
> > @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
> >
> > inherit autotools update-alternatives
> >
> > +EXTRA_OECONF += "--disable-libseccomp"
> > +
>
> On host it makes sense but how about for target recipe ? We do have
> libseccomp support
> Perhaps it’s best to disable it for native and native sdk alone ?
Given the problem reports in the media and the decisions made by most
other distros I think disabling this is probably safest until its been
make more usable (no other distro is shipping this enabled now).
Cheers,
Richard
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: explicitly disable seccomp
2019-10-18 21:28 ` Richard Purdie
@ 2019-10-19 5:26 ` Khem Raj
2020-01-20 12:53 ` Martin Hundebøll
1 sibling, 0 replies; 13+ messages in thread
From: Khem Raj @ 2019-10-19 5:26 UTC (permalink / raw)
To: Richard Purdie; +Cc: openembedded-core
[-- Attachment #1: Type: text/plain, Size: 1663 bytes --]
On Sat, Oct 19, 2019 at 2:58 AM Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:
> On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote:
> >
> >
> > On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.burton@intel.com>
> > wrote:
> > > file will automatically enable seccomp if the seccomp headers are
> > > available, but
> > > the build will fail on Opensuse Tumbleweed because the include
> > > paths are wrong.
> > >
> > > Enabling seccomp is a bad idea because it interacts badly with
> > > pseudo (causing
> > > build failures), so explicitly and globally disable seccomp.
> > >
> > > Signed-off-by: Ross Burton <ross.burton@intel.com>
> > > ---
> > > meta/recipes-devtools/file/file_5.37.bb | 2 ++
> > > 1 file changed, 2 insertions(+)
> > >
> > > diff --git a/meta/recipes-devtools/file/file_5.37.bb
> > > b/meta/recipes-devtools/file/file_5.37.bb
> > > index a840dbc012b..c53a120b840 100644
> > > --- a/meta/recipes-devtools/file/file_5.37.bb
> > > +++ b/meta/recipes-devtools/file/file_5.37.bb
> > > @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
> > >
> > > inherit autotools update-alternatives
> > >
> > > +EXTRA_OECONF += "--disable-libseccomp"
> > > +
> >
> > On host it makes sense but how about for target recipe ? We do have
> > libseccomp support
> > Perhaps it’s best to disable it for native and native sdk alone ?
>
> Given the problem reports in the media and the decisions made by most
> other distros I think disabling this is probably safest until its been
> make more usable (no other distro is shipping this enabled now).
>
Ok makes sense
> Cheers,
>
> Richard
>
>
>
>
>
>
[-- Attachment #2: Type: text/html, Size: 2894 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: explicitly disable seccomp
2019-10-18 21:28 ` Richard Purdie
2019-10-19 5:26 ` Khem Raj
@ 2020-01-20 12:53 ` Martin Hundebøll
2020-01-20 15:45 ` Khem Raj
1 sibling, 1 reply; 13+ messages in thread
From: Martin Hundebøll @ 2020-01-20 12:53 UTC (permalink / raw)
To: Richard Purdie, Khem Raj, Ross Burton; +Cc: openembedded-core
On 18/10/2019 23.28, Richard Purdie wrote:
> On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote:
>>
>>
>> On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.burton@intel.com>
>> wrote:
>>> file will automatically enable seccomp if the seccomp headers are
>>> available, but
>>> the build will fail on Opensuse Tumbleweed because the include
>>> paths are wrong.
>>>
>>> Enabling seccomp is a bad idea because it interacts badly with
>>> pseudo (causing
>>> build failures), so explicitly and globally disable seccomp.
>>>
>>> Signed-off-by: Ross Burton <ross.burton@intel.com>
>>> ---
>>> meta/recipes-devtools/file/file_5.37.bb | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/meta/recipes-devtools/file/file_5.37.bb
>>> b/meta/recipes-devtools/file/file_5.37.bb
>>> index a840dbc012b..c53a120b840 100644
>>> --- a/meta/recipes-devtools/file/file_5.37.bb
>>> +++ b/meta/recipes-devtools/file/file_5.37.bb
>>> @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
>>>
>>> inherit autotools update-alternatives
>>>
>>> +EXTRA_OECONF += "--disable-libseccomp"
>>> +
>>
>> On host it makes sense but how about for target recipe ? We do have
>> libseccomp support
>> Perhaps it’s best to disable it for native and native sdk alone ?
>
> Given the problem reports in the media and the decisions made by most
> other distros I think disabling this is probably safest until its been
> make more usable (no other distro is shipping this enabled now).
Arch Linux enabled libseccomp as of today:
https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/file&id=a52fa0a37bad1f4ab67a934a4e0025e70aa1fd0e
This breaks the use of `file` in do_package():
ERROR: base-files-3.0.14-r89 do_package: Fatal errors occurred in
subprocesses:
Command '['file', '-b',
'/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']'
died with <Signals.SIGSYS: 31>.: Traceback (most recent call last):
File
"/home/martin/clients/connectedcars/yocto/poky/meta/lib/oe/utils.py",
line 272, in run
ret = self._target(*self._args, **self._kwargs)
File
"/home/martin/clients/connectedcars/yocto/poky/meta/lib/oe/package.py",
line 70, 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,
subprocess.CalledProcessError: Command '['file', '-b',
'/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']'
died with <Signals.SIGSYS: 31>.
Disabling libseccomp sandboxing at runtime fixes it for me:
diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
index efd36b3758..bc46d7c27c 100644
--- a/meta/lib/oe/package.py
+++ b/meta/lib/oe/package.py
@@ -67,7 +67,7 @@ def is_kernel_module_signed(path):
# 16 - kernel module
def is_elf(path):
exec_type = 0
- result = subprocess.check_output(["file", "-b", path],
stderr=subprocess.STDOUT).decode("utf-8")
+ result = subprocess.check_output(["file", "-S", "-b", path],
stderr=subprocess.STDOUT).decode("utf-8")
if "ELF" in result:
exec_type |= 1
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: explicitly disable seccomp
2020-01-20 12:53 ` Martin Hundebøll
@ 2020-01-20 15:45 ` Khem Raj
2020-01-20 17:10 ` Ross Burton
0 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2020-01-20 15:45 UTC (permalink / raw)
To: Martin Hundebøll; +Cc: Patches and discussions about the oe-core layer
On Mon, Jan 20, 2020 at 4:53 AM Martin Hundebøll <martin@geanix.com> wrote:
>
> On 18/10/2019 23.28, Richard Purdie wrote:
> > On Fri, 2019-10-18 at 18:03 +0530, Khem Raj wrote:
> >>
> >>
> >> On Fri, Oct 18, 2019 at 4:58 PM Ross Burton <ross.burton@intel.com>
> >> wrote:
> >>> file will automatically enable seccomp if the seccomp headers are
> >>> available, but
> >>> the build will fail on Opensuse Tumbleweed because the include
> >>> paths are wrong.
> >>>
> >>> Enabling seccomp is a bad idea because it interacts badly with
> >>> pseudo (causing
> >>> build failures), so explicitly and globally disable seccomp.
> >>>
> >>> Signed-off-by: Ross Burton <ross.burton@intel.com>
> >>> ---
> >>> meta/recipes-devtools/file/file_5.37.bb | 2 ++
> >>> 1 file changed, 2 insertions(+)
> >>>
> >>> diff --git a/meta/recipes-devtools/file/file_5.37.bb
> >>> b/meta/recipes-devtools/file/file_5.37.bb
> >>> index a840dbc012b..c53a120b840 100644
> >>> --- a/meta/recipes-devtools/file/file_5.37.bb
> >>> +++ b/meta/recipes-devtools/file/file_5.37.bb
> >>> @@ -21,6 +21,8 @@ S = "${WORKDIR}/git"
> >>>
> >>> inherit autotools update-alternatives
> >>>
> >>> +EXTRA_OECONF += "--disable-libseccomp"
> >>> +
> >>
> >> On host it makes sense but how about for target recipe ? We do have
> >> libseccomp support
> >> Perhaps it’s best to disable it for native and native sdk alone ?
> >
> > Given the problem reports in the media and the decisions made by most
> > other distros I think disabling this is probably safest until its been
> > make more usable (no other distro is shipping this enabled now).
>
> Arch Linux enabled libseccomp as of today:
>
> https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/file&id=a52fa0a37bad1f4ab67a934a4e0025e70aa1fd0e
>
> This breaks the use of `file` in do_package():
>
> ERROR: base-files-3.0.14-r89 do_package: Fatal errors occurred in
> subprocesses:
>
> Command '['file', '-b',
> '/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']'
> died with <Signals.SIGSYS: 31>.: Traceback (most recent call last):
>
> File
> "/home/martin/clients/connectedcars/yocto/poky/meta/lib/oe/utils.py",
> line 272, in run
>
> ret = self._target(*self._args, **self._kwargs)
>
> File
> "/home/martin/clients/connectedcars/yocto/poky/meta/lib/oe/package.py",
> line 70, 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,
>
> subprocess.CalledProcessError: Command '['file', '-b',
> '/home/martin/clients/connectedcars/yocto/build/tmp-glibc/work/iwg26-oe-linux-gnueabi/base-files/3.0.14-r89/package/etc/skel/.profile']'
> died with <Signals.SIGSYS: 31>.
>
> Disabling libseccomp sandboxing at runtime fixes it for me:
>
> diff --git a/meta/lib/oe/package.py b/meta/lib/oe/package.py
>
> index efd36b3758..bc46d7c27c 100644
>
> --- a/meta/lib/oe/package.py
>
> +++ b/meta/lib/oe/package.py
>
> @@ -67,7 +67,7 @@ def is_kernel_module_signed(path):
>
> # 16 - kernel module
>
> def is_elf(path):
>
> exec_type = 0
>
> - result = subprocess.check_output(["file", "-b", path],
> stderr=subprocess.STDOUT).decode("utf-8")
>
> + result = subprocess.check_output(["file", "-S", "-b", path],
> stderr=subprocess.STDOUT).decode("utf-8")
>
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
>
>
> if "ELF" in result:
>
> exec_type |= 1
>
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: explicitly disable seccomp
2020-01-20 15:45 ` Khem Raj
@ 2020-01-20 17:10 ` Ross Burton
2020-01-20 18:53 ` Khem Raj
2020-03-31 10:57 ` [OE-core] " Jan Luebbe
0 siblings, 2 replies; 13+ messages in thread
From: Ross Burton @ 2020-01-20 17:10 UTC (permalink / raw)
To: Khem Raj, Martin Hundebøll
Cc: Patches and discussions about the oe-core layer
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.
Ross
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [PATCH] file: explicitly disable seccomp
2020-01-20 17:10 ` Ross Burton
@ 2020-01-20 18:53 ` Khem Raj
2020-03-31 10:57 ` [OE-core] " Jan Luebbe
1 sibling, 0 replies; 13+ messages in thread
From: Khem Raj @ 2020-01-20 18:53 UTC (permalink / raw)
To: Ross Burton; +Cc: Patches and discussions about the oe-core layer
[-- Attachment #1: Type: text/plain, Size: 1104 bytes --]
On Mon, Jan 20, 2020 at 9:10 AM Ross Burton <ross.burton@intel.com> 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.
>
It’s is not different than what I was saying how it inserts itself into
process is a detail which is hidden from operating system
However I think file is only one case when used along with libseccomp there
could be more use cases if other host tools we use start using it
So I wonder If we should start building own native versions of tools or
make it part of build tools tarball
Or perhaps just publish a self built container and not worry about what
distros are doing underneath
>
> There's nothing pseudo can do to solve this.
>
> Ross
>
[-- Attachment #2: Type: text/html, Size: 1685 bytes --]
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [OE-core] [PATCH] file: explicitly disable seccomp
2020-01-20 17:10 ` Ross Burton
2020-01-20 18:53 ` Khem Raj
@ 2020-03-31 10:57 ` Jan Luebbe
2020-03-31 11:04 ` Richard Purdie
2020-04-03 13:36 ` Richard Purdie
1 sibling, 2 replies; 13+ messages in thread
From: Jan Luebbe @ 2020-03-31 10:57 UTC (permalink / raw)
To: Ross Burton, Khem Raj, Martin Hundebøll
Cc: Patches and discussions about the oe-core layer, Enrico Jorns
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? :)
Regards,
Jan
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [OE-core] [PATCH] file: explicitly disable seccomp
2020-03-31 10:57 ` [OE-core] " Jan Luebbe
@ 2020-03-31 11:04 ` Richard Purdie
2020-04-03 13:36 ` Richard Purdie
1 sibling, 0 replies; 13+ messages in thread
From: Richard Purdie @ 2020-03-31 11:04 UTC (permalink / raw)
To: Jan Luebbe, Ross Burton, Khem Raj, Martin Hundebøll
Cc: Patches and discussions about the oe-core layer, Enrico Jorns
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 don't think we'd thought of that, I like the idea in principle...
Cheers,
Richard
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [OE-core] [PATCH] file: explicitly disable seccomp
2020-03-31 10:57 ` [OE-core] " Jan Luebbe
2020-03-31 11:04 ` Richard Purdie
@ 2020-04-03 13:36 ` Richard Purdie
2020-04-03 14:23 ` Khem Raj
1 sibling, 1 reply; 13+ messages in thread
From: Richard Purdie @ 2020-04-03 13:36 UTC (permalink / raw)
To: Jan Luebbe, Ross Burton, Khem Raj, Martin Hundebøll
Cc: Patches and discussions about the oe-core layer, Enrico Jorns
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!
Cheers,
Richard
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [OE-core] [PATCH] file: explicitly disable seccomp
2020-04-03 13:36 ` Richard Purdie
@ 2020-04-03 14:23 ` Khem Raj
2020-04-03 17:53 ` Richard Purdie
0 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2020-04-03 14:23 UTC (permalink / raw)
To: Richard Purdie
Cc: Jan Luebbe, Ross Burton, Martin Hundebøll,
Patches and discussions about the oe-core layer, Enrico Jorns
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,
> Cheers,
>
> Richard
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [OE-core] [PATCH] file: explicitly disable seccomp
2020-04-03 14:23 ` Khem Raj
@ 2020-04-03 17:53 ` Richard Purdie
0 siblings, 0 replies; 13+ messages in thread
From: Richard Purdie @ 2020-04-03 17:53 UTC (permalink / raw)
To: Khem Raj
Cc: Jan Luebbe, Ross Burton, Martin Hundebøll,
Patches and discussions about the oe-core layer, Enrico Jorns
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
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2020-04-03 17:53 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-10-18 11:28 [PATCH] file: explicitly disable seccomp Ross Burton
2019-10-18 12:33 ` Khem Raj
2019-10-18 21:28 ` Richard Purdie
2019-10-19 5:26 ` Khem Raj
2020-01-20 12:53 ` Martin Hundebøll
2020-01-20 15:45 ` Khem Raj
2020-01-20 17:10 ` Ross Burton
2020-01-20 18:53 ` Khem Raj
2020-03-31 10:57 ` [OE-core] " Jan Luebbe
2020-03-31 11:04 ` Richard Purdie
2020-04-03 13:36 ` Richard Purdie
2020-04-03 14:23 ` Khem Raj
2020-04-03 17:53 ` Richard Purdie
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.