@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]: - https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418 + [1]: https://code.launchpad.net/~paelzer/ubuntu/+source/libseccomp/+git/libseccomp/+merge/362906/comments/944418 + [2]: https://github.com/seccomp/libseccomp/commit/c842c2f6c203ad9da37ca60219172aa0be68d26a -- 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@lists.launchpad.net Unsubscribe : https://launchpad.net/~touch-packages More help : https://help.launchpad.net/ListHelp
