| 2019-02-11 07:27:43 |
Christian Ehrhardt |
bug |
|
|
added bug |
| 2019-02-11 07:27:55 |
Christian Ehrhardt |
affects |
docker.io (Ubuntu) |
libseccomp (Ubuntu) |
|
| 2019-02-11 07:29:08 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Cosmic |
|
| 2019-02-11 07:29:08 |
Christian Ehrhardt |
bug task added |
|
libseccomp (Ubuntu Cosmic) |
|
| 2019-02-11 07:29:08 |
Christian Ehrhardt |
nominated for series |
|
Ubuntu Bionic |
|
| 2019-02-11 07:29:08 |
Christian Ehrhardt |
bug task added |
|
libseccomp (Ubuntu Bionic) |
|
| 2019-02-11 07:29:14 |
Christian Ehrhardt |
libseccomp (Ubuntu): status |
New |
Fix Released |
|
| 2019-02-11 07:29:16 |
Christian Ehrhardt |
libseccomp (Ubuntu Cosmic): status |
New |
Fix Released |
|
| 2019-02-11 07:29:19 |
Christian Ehrhardt |
libseccomp (Ubuntu Bionic): status |
New |
Triaged |
|
| 2019-02-11 07:29:44 |
Christian Ehrhardt |
description |
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet. |
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418 |
|
| 2019-02-11 07:31:37 |
Christian Ehrhardt |
bug |
|
|
added subscriber Seth Arnold |
| 2019-02-11 07:31:51 |
Christian Ehrhardt |
bug |
|
|
added subscriber Tyler Hicks |
| 2019-02-11 07:37:28 |
Christian Ehrhardt |
description |
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418 |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions.
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418 |
|
| 2019-02-11 07:39:21 |
Christian Ehrhardt |
description |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions.
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418 |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2].
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a |
|
| 2019-02-11 07:47:04 |
Christian Ehrhardt |
description |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2].
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2][3].
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
* we also missed the former update for kernel 4.9 [3] as the official
releases of the lib are rather slow.
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
[3]: https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c |
|
| 2019-02-11 07:56:22 |
Christian Ehrhardt |
description |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2][3].
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
* we also missed the former update for kernel 4.9 [3] as the official
releases of the lib are rather slow.
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
[3]: https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2][3][4].
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
* we also missed the former update for kernel 4.9 [3] AND 4.10 [4] as the
official releases of the lib are rather seldom.
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
[3]: https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c
[4]: https://github.com/seccomp/libseccomp/commit/116b3c1a2e1db53cc35b74f30c080f5265faa674 |
|
| 2019-02-11 08:12:29 |
Launchpad Janitor |
merge proposal linked |
|
https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906 |
|
| 2019-02-12 07:46:51 |
Christian Ehrhardt |
description |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2][3][4].
[Test Case]
* TODO
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
* we also missed the former update for kernel 4.9 [3] AND 4.10 [4] as the
official releases of the lib are rather seldom.
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
[3]: https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c
[4]: https://github.com/seccomp/libseccomp/commit/116b3c1a2e1db53cc35b74f30c080f5265faa674 |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2][3][4].
[Test Case]
* Note: a lot of this is kernel dependent it should work with the intended SRU target of Bionic with kernel 4.15 or 4.18, but be careful to run it there (e.g. not a LXD container on Xenials 4.4 kernel)
* we modify the already existing autopkgtest for this SRU verification
# Prep
$ apt install ubuntu-dev-tools build-essential linux-libc-dev libseccomp-dev libseccomp2 seccomp
$ pull-lp-source libseccomp bionic
$ cd libseccomp-2.3.1
$ export ADTTMP=$(mktemp -d); echo $ADTTMP
# run original tests as-is (should pass/fail as expected)
$ ./debian/tests/test-filter
# add new syscalls of this SRU
$ cp debian/tests/data/safe.filter debian/tests/data/newcodes.filter
$ printf "preadv2\npwritev2\npkey_mprotect\npkey_alloc\npkey_free\nget_tls\ns390_guarded_storage\ns390_sthyi\n" >> debian/tests/data/newcodes.filter
# remove unknown calls (x86 4.18 kernel)
sed -i -e '/^_exit$/d' -e '/^fstatvfs$/d' -e '/^llseek$/d' -e '/^pread$/d' -e '/^pselect$/d' -e '/^pwrite$/d' -e '/^sigtimedwait$/d' -e '/^sigwaitinfo$/d' -e '/^statvfs$/d' debian/tests/data/newcodes.filter
# make unknown call a fail
$ sed -i -e '111s/continue;/{fprintf(stderr, "failed to find %s\\n",buf);rc = -1;goto out;}/' debian/tests/src/test-seccomp.c
# run this special test and check return value
${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?
Without the fix it will fail like:
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
failed to find preadv2
seccomp_load_filters failed with -1
1
But with the fix applied those new calls will work:
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
Tue Feb 12 07:41:05 UTC 2019
0
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
* we also missed the former update for kernel 4.9 [3] AND 4.10 [4] as the
official releases of the lib are rather seldom.
* In general there already are build time tests and autopkgtests in the
package already. So coverage of "old calls" for regressions is already
good.
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
[3]: https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c
[4]: https://github.com/seccomp/libseccomp/commit/116b3c1a2e1db53cc35b74f30c080f5265faa674 |
|
| 2019-02-12 07:51:09 |
Christian Ehrhardt |
libseccomp (Ubuntu Bionic): assignee |
|
Christian Ehrhardt (paelzer) |
|
| 2019-02-12 07:51:15 |
Christian Ehrhardt |
libseccomp (Ubuntu Bionic): status |
Triaged |
In Progress |
|
| 2019-02-27 20:35:44 |
Brian Murray |
libseccomp (Ubuntu Bionic): status |
In Progress |
Fix Committed |
|
| 2019-02-27 20:35:47 |
Brian Murray |
bug |
|
|
added subscriber Ubuntu Stable Release Updates Team |
| 2019-02-27 20:35:49 |
Brian Murray |
bug |
|
|
added subscriber SRU Verification |
| 2019-02-27 20:35:54 |
Brian Murray |
tags |
|
verification-needed verification-needed-bionic |
|
| 2019-02-28 09:46:34 |
Christian Ehrhardt |
description |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2][3][4].
[Test Case]
* Note: a lot of this is kernel dependent it should work with the intended SRU target of Bionic with kernel 4.15 or 4.18, but be careful to run it there (e.g. not a LXD container on Xenials 4.4 kernel)
* we modify the already existing autopkgtest for this SRU verification
# Prep
$ apt install ubuntu-dev-tools build-essential linux-libc-dev libseccomp-dev libseccomp2 seccomp
$ pull-lp-source libseccomp bionic
$ cd libseccomp-2.3.1
$ export ADTTMP=$(mktemp -d); echo $ADTTMP
# run original tests as-is (should pass/fail as expected)
$ ./debian/tests/test-filter
# add new syscalls of this SRU
$ cp debian/tests/data/safe.filter debian/tests/data/newcodes.filter
$ printf "preadv2\npwritev2\npkey_mprotect\npkey_alloc\npkey_free\nget_tls\ns390_guarded_storage\ns390_sthyi\n" >> debian/tests/data/newcodes.filter
# remove unknown calls (x86 4.18 kernel)
sed -i -e '/^_exit$/d' -e '/^fstatvfs$/d' -e '/^llseek$/d' -e '/^pread$/d' -e '/^pselect$/d' -e '/^pwrite$/d' -e '/^sigtimedwait$/d' -e '/^sigwaitinfo$/d' -e '/^statvfs$/d' debian/tests/data/newcodes.filter
# make unknown call a fail
$ sed -i -e '111s/continue;/{fprintf(stderr, "failed to find %s\\n",buf);rc = -1;goto out;}/' debian/tests/src/test-seccomp.c
# run this special test and check return value
${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?
Without the fix it will fail like:
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
failed to find preadv2
seccomp_load_filters failed with -1
1
But with the fix applied those new calls will work:
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
Tue Feb 12 07:41:05 UTC 2019
0
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
* we also missed the former update for kernel 4.9 [3] AND 4.10 [4] as the
official releases of the lib are rather seldom.
* In general there already are build time tests and autopkgtests in the
package already. So coverage of "old calls" for regressions is already
good.
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
[3]: https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c
[4]: https://github.com/seccomp/libseccomp/commit/116b3c1a2e1db53cc35b74f30c080f5265faa674 |
[Impact]
* The libseccomp library provides an easy to use, platform independent,
interface to the Linux Kernel's syscall filtering mechanism. But it can
only "control" those syscalls it knows about. Therefore staying up to
date with newer kernels is a requirement to be fully funcitonal.
* At the time 18.04 was released with the 4.15 kernel the new definitions
were not yet released for libseccomp - lets fix this mismatch by
backporting the new syscall definitions [2][3][4].
[Test Case]
* Note: a lot of this is kernel dependent it should work with the intended SRU target of Bionic with kernel 4.15 or 4.18, but be careful to run it there (e.g. not a LXD container on Xenials 4.4 kernel)
* we modify the already existing autopkgtest for this SRU verification
# Prep
$ apt install ubuntu-dev-tools build-essential linux-libc-dev libseccomp-dev libseccomp2 seccomp
$ pull-lp-source libseccomp bionic
$ cd libseccomp-2.3.1
$ export ADTTMP=$(mktemp -d); echo $ADTTMP
# run original tests as-is (should pass/fail as expected)
$ ./debian/tests/test-filter
# add new syscalls of this SRU
$ cp debian/tests/data/safe.filter debian/tests/data/newcodes.filter
$ printf "preadv2\npwritev2\npkey_mprotect\npkey_alloc\npkey_free\nget_tls\ns390_guarded_storage\ns390_sthyi\n" >> debian/tests/data/newcodes.filter
# remove unknown calls (x86 4.18 kernel)
sed -i -e '/^_exit$/d' -e '/^fstatvfs$/d' -e '/^llseek$/d' -e '/^pread$/d' -e '/^pselect$/d' -e '/^pwrite$/d' -e '/^sigtimedwait$/d' -e '/^sigwaitinfo$/d' -e '/^statvfs$/d' debian/tests/data/newcodes.filter
# make unknown call a fail
$ sed -i -e '111s/continue;/{fprintf(stderr, "failed to find %s\\n",buf);rc = -1;goto out;}/' debian/tests/src/test-seccomp.c
# build new test binary
$ export ADTTMP=$(mktemp -d); echo $ADTTMP
$ ./debian/tests/test-filter
# run this special test and check return value
${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?
Without the fix it will fail like:
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
failed to find preadv2
seccomp_load_filters failed with -1
1
But with the fix applied those new calls will work:
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
Tue Feb 12 07:41:05 UTC 2019
0
[Regression Potential]
* This isn't adding new active code like functions, but only extending
the definitions of per-arch syscall numbers to be aware of the newer
syscalls that were added in the kernel. Therefore no old use-cases
should regress (they are not touched). The only change in behavior for
an SRU POV would be that things that got denied so far (e.g. if you
tried to set such a new syscall through libseccomp) was denied before
and would now work. I think that is exactly the intention of the SRU
and not a regression.
[Other Info]
* Requested while security reviewing an libseccomp SRU to have one update
for both [1].
* we also missed the former update for kernel 4.9 [3] AND 4.10 [4] as the
official releases of the lib are rather seldom.
* In general there already are build time tests and autopkgtests in the
package already. So coverage of "old calls" for regressions is already
good.
---
This came up while working on bug 1755250 which asked for statx.
But on the review of that it was pointed out [1] that it would be great to support further new kernel syscall defines - this isn't even looking at HWE kernels for Bionic, but "just" adding those which are there for the 4.15 kernel Bionic was released with.
With the HWE kernels in mind there would be even more one might want to add, but there is no newer such update in the upstream repo yet.
[1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418
[2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a
[3]: https://github.com/seccomp/libseccomp/commit/d9102f12fd39bd77151a1f630fcfc8c80f86c55c
[4]: https://github.com/seccomp/libseccomp/commit/116b3c1a2e1db53cc35b74f30c080f5265faa674 |
|
| 2019-02-28 09:50:52 |
Christian Ehrhardt |
tags |
verification-needed verification-needed-bionic |
verification-done verification-done-bionic |
|
| 2019-03-11 18:33:13 |
Launchpad Janitor |
libseccomp (Ubuntu Bionic): status |
Fix Committed |
Fix Released |
|
| 2019-03-11 18:33:25 |
Łukasz Zemczak |
removed subscriber Ubuntu Stable Release Updates Team |
|
|
|
