[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
This bug was fixed in the package libseccomp - 2.3.1-2.1ubuntu4.1
---
libseccomp (2.3.1-2.1ubuntu4.1) bionic; urgency=medium
* d/p/lp-1755250-add-the-statx-syscall.patch: add statx support (LP: #1755250)
* d/p/lp-1815415-*: Add syscalls up to kernel 4.15 (LP: #1815415)
-- Christian Ehrhardt Fri, 08 Feb
2019 09:17:23 +0100
** Changed in: libseccomp (Ubuntu Bionic)
Status: Fix Committed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415
Title:
please update libseccomp for newer kernel syscalls
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Bionic:
Fix Released
Status in libseccomp source package in Cosmic:
Fix Released
Bug 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
# 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]:
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
Testing as-is
$ ${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
failed to find preadv2
seccomp_load_filters failed with -1
1
Update to version in proposed:
$ sudo apt install libseccomp2/bionic-proposed
Reading package lists... Done
Building dependency tree
Reading state information... Done
Selected version '2.3.1-2.1ubuntu4.1' (Ubuntu:18.04/bionic-proposed [amd64])
for 'libseccomp2'
The following package was automatically installed and is no longer required:
grub-pc-bin
Use 'sudo apt autoremove' to remove it.
The following additional packages will be installed:
libseccomp-dev
The following packages will be upgraded:
libseccomp-dev libseccomp2
2 upgraded, 0 newly installed, 0 to remove and 26 not upgraded.
Need to get 96.9 kB of archives.
After this operation, 15.4 kB of additional disk space will be used.
Do you want to continue? [Y/n] y
Get:1 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64
libseccomp-dev amd64 2.3.1-2.1ubuntu4.1 [57.8 kB]
Get:2 http://archive.ubuntu.com/ubuntu bionic-proposed/main amd64 libseccomp2
amd64 2.3.1-2.1ubuntu4.1 [39.1 kB]
Fetched 96.9 kB in 0s (755 kB/s)
(Reading database ... 102759 files and directories currently installed.)
Preparing to unpack .../libseccomp-dev_2.3.1-2.1ubuntu4.1_amd64.deb ...
Unpacking libseccomp-dev:amd64 (2.3.1-2.1ubuntu4.1) over (2.3.1-2.1ubuntu4) ...
Preparing to unpack .../libseccomp2_2.3.1-2.1ubuntu4.1_amd64.deb ...
Unpacking libseccomp2:amd64 (2.3.1-2.1ubuntu4.1) over (2.3.1-2.1ubuntu4) ...
Setting up libseccomp2:amd64 (2.3.1-2.1ubuntu4.1) ...
Setting up libseccomp-dev:amd64 (2.3.1-2.1ubuntu4.1) ...
Processing triggers for libc-bin (2.27-3ubuntu1) ...
Processing triggers for man-db (2.8.3-2ubuntu0.1) ...
Retest the case:
$ ${ADTTMP}/exe ./debian/tests/data/newcodes.filter /bin/date; echo $?
DEBUG: seccomp_load_filters ./debian/tests/data/newcodes.filter
Thu Feb 28 09:50:23 UTC 2019
0
Working fine now (all new syscalls)
Setting verified
** Tags removed: verification-needed verification-needed-bionic
** Tags added: verification-done verification-done-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415
Title:
please update libseccomp for newer kernel syscalls
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Bionic:
Fix Committed
Status in libseccomp source package in Cosmic:
Fix Released
Bug 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
# 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
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
Added improved test ordering to the description
** Description changed:
[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
+ * 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.
+ * 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
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415
Title:
please update libseccomp for newer kernel syscalls
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Bionic:
Fix Committed
Status in libseccomp source package in Cosmic:
Fix Released
Bug description:
[Impact]
*
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
Hello Christian, or anyone else affected,
Accepted libseccomp into bionic-proposed. The package will build now and
be available at
https://launchpad.net/ubuntu/+source/libseccomp/2.3.1-2.1ubuntu4.1 in a
few hours, and then in the -proposed repository.
Please help us by testing this new package. See
https://wiki.ubuntu.com/Testing/EnableProposed for documentation on how
to enable and use -proposed. Your feedback will aid us getting this
update out to other Ubuntu users.
If this package fixes the bug for you, please add a comment to this bug,
mentioning the version of the package you tested and change the tag from
verification-needed-bionic to verification-done-bionic. If it does not
fix the bug for you, please add a comment stating that, and change the
tag to verification-failed-bionic. In either case, without details of
your testing we will not be able to proceed.
Further information regarding the verification process can be found at
https://wiki.ubuntu.com/QATeam/PerformingSRUVerification . Thank you in
advance for helping!
N.B. The updated package will be released to -updates after the bug(s)
fixed by this package have been verified and the package has been in
-proposed for a minimum of 7 days.
** Changed in: libseccomp (Ubuntu Bionic)
Status: In Progress => Fix Committed
** Tags added: verification-needed verification-needed-bionic
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415
Title:
please update libseccomp for newer kernel syscalls
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Bionic:
Fix Committed
Status in libseccomp source package in Cosmic:
Fix Released
Bug 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"
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
Thanks Christian, very thorough.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415
Title:
please update libseccomp for newer kernel syscalls
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Bionic:
In Progress
Status in libseccomp source package in Cosmic:
Fix Released
Bug 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1815415/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
FYI (to find it easier) logs of the new build:
- autopkgtest with new version
https://objectstorage.prodstack4-5.canonical.com/v1/AUTH_77e2ada1e7a84929a74ba3b87153c0ac/autopkgtest-bionic-ci-train-ppa-service-3640/bionic/amd64/libs/libseccomp/20190211_095659_0b835@/log.gz
- build time tests
https://launchpadlibrarian.net/410848161/buildlog_ubuntu-bionic-amd64.libseccomp_2.3.1-2.1ubuntu5~ppa2_BUILDING.txt.gz
** Changed in: libseccomp (Ubuntu Bionic)
Assignee: (unassigned) => Christian Ehrhardt (paelzer)
** Changed in: libseccomp (Ubuntu Bionic)
Status: Triaged => In Progress
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415
Title:
please update libseccomp for newer kernel syscalls
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Bionic:
In Progress
Status in libseccomp source package in Cosmic:
Fix Released
Bug 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]:
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
All pre-checks and tests complete, and uploaded to the SRU review queue
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to libseccomp in Ubuntu.
https://bugs.launchpad.net/bugs/1815415
Title:
please update libseccomp for newer kernel syscalls
Status in libseccomp package in Ubuntu:
Fix Released
Status in libseccomp source package in Bionic:
In Progress
Status in libseccomp source package in Cosmic:
Fix Released
Bug 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
To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1815415/+subscriptions
--
Mailing list: https://launchpad.net/~touch-packages
Post to : touch-packages@lists.launchpad.net
Unsubscribe : https://launchpad.net/~touch-packages
More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
Thanks for the reviews - I'll have to come up with some tests on my own
then ...
In general there already are build time tests and autopkgtests in the package.
So coverage of "old calls" for regressions is already good.
Fortunately the autopkgtests seem to be extendable for an explicit verification
of a few of the new calls. IMHO there is no need to modify the packages test as
run on autopkgtest for these more rare calls - the are focused on use cases
like snaps which they got added for.
We need to:
- add the new calls
- make it fail on unknown calls (without it says "syscall not available on this
arch/kernel - as this is a syscall whitelist its ok and the error can be ignored
- remove some syscalls that never (or no more) exist(ed) that way
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)
# 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
Tested on the PPA builds and working - adding these as SRU test & verification
steps
** Description changed:
[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
+ * 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
Re: [Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
On Mon, Feb 11, 2019 at 07:38:28AM -, Christian Ehrhardt wrote: > @Seth / @Tyler - Hi, you asked for the change, but I'd want to ask for > something as well :-) Do you have any testcases from your security work > that we could reuse here to check the SRU for SRU verification? It doesn't look we do; we've got some kernel-level seccomp filter checks in place for testing the kernel, but these use prctl(2) directly. Thanks -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1815415 Title: please update libseccomp for newer kernel syscalls Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Bionic: Triaged Status in libseccomp source package in Cosmic: Fix Released Bug 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1815415/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
Sorry about the question about s390 syscalls in unrelated syscall tables; that patch accurately reflected upstream's code. Looks good to me, thanks. -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1815415 Title: please update libseccomp for newer kernel syscalls Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Bionic: Triaged Status in libseccomp source package in Cosmic: Fix Released Bug 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1815415/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
I combined the requested changes in the PPA [1] and version ~ppa2 is building now. Later autopkgtests will be kicked on bileto [2] to pre- check those as well. I updated the MP for re-review accordingly. [1]: https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/3640 [2]: https://bileto.ubuntu.com/#/ticket/3640 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1815415 Title: please update libseccomp for newer kernel syscalls Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Bionic: Triaged Status in libseccomp source package in Cosmic: Fix Released Bug 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1815415/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
** Merge proposal linked: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1815415 Title: please update libseccomp for newer kernel syscalls Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Bionic: Triaged Status in libseccomp source package in Cosmic: Fix Released Bug 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1815415/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to : touch-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
Combining all those also allows us to take the changes (since they only add definitions the only context they had were "each other) without any backport noise. ** Description changed: [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]. + 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] as the official -releases of the lib are rather slow. + * 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 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1815415 Title: please update libseccomp for newer kernel syscalls Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Bionic: Triaged Status in libseccomp source package in Cosmic: Fix Released Bug 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
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
** Description changed: [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]. + 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 -- You received this bug notification because you are a member of Ubuntu Touch seeded packages, which is subscribed to libseccomp in Ubuntu. https://bugs.launchpad.net/bugs/1815415 Title: please update libseccomp for newer kernel syscalls Status in libseccomp package in Ubuntu: Fix Released Status in libseccomp source package in Bionic: Triaged Status in libseccomp source package in Cosmic: Fix Released Bug 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 To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/libseccomp/+bug/1815415/+subscriptions -- Mailing list: https://launchpad.net/~touch-packages Post to :
[Touch-packages] [Bug 1815415] Re: please update libseccomp for newer kernel syscalls
@Seth / @Tyler - Hi, you asked for the change, but I'd want to ask for something as well :-) Do you have any testcases from your security work that we could reuse here to check the SRU for SRU verification? ** Description changed: + [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 ** Description changed: [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. + * 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. + * 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 + * 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. + * 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]. + + * 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]: -
