The following changes since commit 445514206988935e5ef0e80588d7481aa3cd3b7b:
Linux 4.9.322 (2022-07-07 17:30:12 +0200)
are available in the Git repository at:
https://github.com/Flamefire/android_kernel_sony_msm8998.git lsm_hooks_backport_4.9
for you to fetch changes up to 911aa0e49633be52c7a2de8c99de87b6bf3a7604:
LSM: Initialize security_hook_heads upon registration. (2022-07-09 12:51:42 +0200)
All commits are cherry-picks/backports from mainline. The intend was to apply the last commit ("LSM: Initialize security_hook_heads upon registration.") with as few changes as possible. This revealed added/removed/changed hooks and related changes which seem valuable to have in 4.9 and via the CIP in 4.4 SLTS. For additional Context: I initially backported those directly to CIPs v4.4-st14 and tested those on an ARM64 Android device from SONY. [1]
I'm open for breaking down the changes into smaller batches. If that is beneficial please advice on how/where to split this batch. But for now I thought it would be useful to see the full set of changes intended.
References: - https://lore.kernel.org/all/1478812710-17190-2-git-send-email-agruenba@redha... - https://lkml.org/lkml/2016/6/24/564 - https://patchwork.kernel.org/project/linux-hardening/patch/alpine.LRH.2.20.1... - https://www.mail-archive.com/linux-kernel@vger.kernel.org/msg2415740.html - https://lkml.org/lkml/2016/6/24/564
---------------------------------------------------------------- Andreas Gruenbacher (4): proc: Pass file mode to proc_pid_make_inode selinux: Minor cleanups selinux: Clean up initialization of isec->sclass selinux: Convert isec->lock into a spinlock
Casey Schaufler (1): LSM: Add /sys/kernel/security/lsm
James Morris (2): security: introduce CONFIG_SECURITY_WRITABLE_HOOKS security: mark LSM hooks as __ro_after_init
Ondrej Mosnacek (1): selinux: drop super_block backpointer from superblock_security_struct
Paul Moore (2): selinux: fix inode_doinit_with_dentry() LABEL_INVALID error handling lsm,selinux: pass flowi_common instead of flowi to the LSM hooks
Stephen Smalley (2): prlimit,security,selinux: add a security hook for prlimit security,selinux,smack: kill security_task_wait hook
Tetsuo Handa (1): LSM: Initialize security_hook_heads upon registration.
Tianyue Ren (1): selinux: fix error initialization in inode_doinit_with_dentry()
bauen1 (1): selinux: allow dontauditx and auditallowx rules to take effect without allowx
Documentation/security/LSM.txt | 7 ++ fs/proc/base.c | 23 ++-- fs/proc/fd.c | 6 +- fs/proc/internal.h | 2 +- fs/proc/namespaces.c | 3 +- include/linux/lsm_hooks.h | 50 +++++---- include/linux/security.h | 42 +++++--- include/net/flow.h | 10 ++ include/net/route.h | 6 +- kernel/exit.c | 19 +--- kernel/sys.c | 30 +++--- net/dccp/ipv4.c | 2 +- net/dccp/ipv6.c | 6 +- net/ipv4/icmp.c | 4 +- net/ipv4/inet_connection_sock.c | 4 +- net/ipv4/ip_output.c | 2 +- net/ipv4/ping.c | 2 +- net/ipv4/raw.c | 2 +- net/ipv4/syncookies.c | 2 +- net/ipv4/udp.c | 2 +- net/ipv6/af_inet6.c | 2 +- net/ipv6/icmp.c | 6 +- net/ipv6/inet6_connection_sock.c | 4 +- net/ipv6/netfilter/ip6t_SYNPROXY.c | 2 +- net/ipv6/netfilter/nf_reject_ipv6.c | 2 +- net/ipv6/ping.c | 2 +- net/ipv6/raw.c | 2 +- net/ipv6/syncookies.c | 2 +- net/ipv6/tcp_ipv6.c | 4 +- net/ipv6/udp.c | 2 +- net/l2tp/l2tp_ip6.c | 2 +- net/xfrm/xfrm_state.c | 6 +- security/Kconfig | 5 + security/apparmor/lsm.c | 5 +- security/commoncap.c | 5 +- security/inode.c | 26 ++++- security/security.c | 426 +++++++++++--------------------------------------------------------------- security/selinux/Kconfig | 6 ++ security/selinux/hooks.c | 156 +++++++++++++++++---------- security/selinux/include/classmap.h | 2 +- security/selinux/include/objsec.h | 6 +- security/selinux/include/xfrm.h | 2 +- security/selinux/selinuxfs.c | 4 +- security/selinux/ss/services.c | 4 +- security/selinux/xfrm.c | 8 +- security/smack/smack_lsm.c | 24 +---- security/tomoyo/tomoyo.c | 4 +- security/yama/yama_lsm.c | 4 +- 48 files changed, 359 insertions(+), 588 deletions(-)
On Sat, Jul 09, 2022 at 02:07:17PM +0200, Alexander Grund wrote:
The following changes since commit 445514206988935e5ef0e80588d7481aa3cd3b7b:
Linux 4.9.322 (2022-07-07 17:30:12 +0200)
are available in the Git repository at:
https://github.com/Flamefire/android_kernel_sony_msm8998.git lsm_hooks_backport_4.9
I can not take a git pull for stable patches, as my bot says:
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
Please just send them to us in patch form like all other stable submissions.
for you to fetch changes up to 911aa0e49633be52c7a2de8c99de87b6bf3a7604:
LSM: Initialize security_hook_heads upon registration. (2022-07-09 12:51:42 +0200)
All commits are cherry-picks/backports from mainline. The intend was to apply the last commit ("LSM: Initialize security_hook_heads upon registration.") with as few changes as possible.
Why?
This revealed added/removed/changed hooks and related changes which seem valuable to have in 4.9 and via the CIP in 4.4 SLTS.
What is "CIP"?
For additional Context: I initially backported those directly to CIPs v4.4-st14 and tested those on an ARM64 Android device from SONY. [1]
I have no context or understand this, sorry :(
thanks,
greg k-h
Please just send them to us in patch form like all other stable submissions.
Sorry I'm new to this kernel list. I'll send 1 patch of this series in a new mail (as a test). Please bear with me if there are any mistakes, the next ones will then be better.
for you to fetch changes up to 911aa0e49633be52c7a2de8c99de87b6bf3a7604:
LSM: Initialize security_hook_heads upon registration. (2022-07-09 12:51:42 +0200)
All commits are cherry-picks/backports from mainline. The intend was to apply the last commit ("LSM: Initialize security_hook_heads upon registration.") with as few changes as possible.
Why?
The conflicts come from added/removed/changed hooks. As noted below those changes seem to be valuable. It is possible to apply the above commit first, but then every of the other commits will need conflict resolution. Hence first I backported the changes to the Hooks and eventually apply that initialization change which also allows to check for differences in the hooks between mainline and 4.9.y.
This revealed added/removed/changed hooks and related changes which seem valuable to have in 4.9 and via the CIP in 4.4 SLTS.
What is "CIP"?
The Civil Infrastructure Platform (CIP) e.g. maintains LTS kernel trees which are now End of Life but still used. They call that SLTS ("Super Long Term Support") and there is e.g. a 4.4.y branch with backports from the 4.9.y LTS branch. That kernel is e.g. used in many Android phones. So in summary I'd like to backport changes to the security system from mainline to 4.9 from where they will be backported to 4.4 (by CIP) and from there included in Android builds still using the kernel.
For additional Context: I initially backported those directly to CIPs v4.4-st14 and tested those on an ARM64 Android device from SONY. [1]
I have no context or understand this, sorry :(
My bad, I forgot to include the link. It is [2] which describes a bit more details of why I wanted the changes in a kernel tree I maintain for a SONY device. Summary: The fix for CVE-2021-39686 benefits from the last commit (LSM: Initialize security_hook_heads upon registration) while the others enhance the security.
Thanks for your patience, Alex
[1] https://wiki.linuxfoundation.org/civilinfrastructureplatform/start [2] https://github.com/Flamefire/android_kernel_sony_msm8998/pull/24
On Sun, Jul 10, 2022 at 12:44:34PM +0200, Alexander Grund wrote:
Please just send them to us in patch form like all other stable submissions.
Sorry I'm new to this kernel list. I'll send 1 patch of this series in a new mail (as a test). Please bear with me if there are any mistakes, the next ones will then be better.
As my bot says, this is all documented:
<formletter>
This is not the correct way to submit patches for inclusion in the stable kernel tree. Please read: https://www.kernel.org/doc/html/latest/process/stable-kernel-rules.html for how to do this properly.
</formletter>
Make sure the patches you are submitting follows those rules on what is able to be accepted.
The Civil Infrastructure Platform (CIP) e.g. maintains LTS kernel trees which are now End of Life but still used. They call that SLTS ("Super Long Term Support") and there is e.g. a 4.4.y branch with backports from the 4.9.y LTS branch. That kernel is e.g. used in many Android phones.
What 4.4.y Android devices are still supported by their vendors? And are they still getting kernel updates?
thanks,
greg k-h
On 10.07.22 13:06, Greg KH wrote:
Make sure the patches you are submitting follows those rules on what is able to be accepted.
Looks like I have to exclude a couple of patches especially due to the 100-lines rule. That especially hits the last one replacing 350 lines initialization code by 6 lines doing the same but avoiding potential errors by missing some initialization.
The Civil Infrastructure Platform (CIP) e.g. maintains LTS kernel trees which are now End of Life but still used. They call that SLTS ("Super Long Term Support") and there is e.g. a 4.4.y branch with backports from the 4.9.y LTS branch. That kernel is e.g. used in many Android phones.
What 4.4.y Android devices are still supported by their vendors? And are they still getting kernel updates?
Actually the issue is that those devices are not supported by their vendors anymore, so they may only get updates through LineageOS. That is a third-party Android build where maintainers rely on proprietary binaries from the original phone which are tied to a specific kernel. Hence when the device falls out of support having a 4.4 kernel in the last release there is no way for those maintainers to switch to a newer kernel. That's the situation e.g. I am in right now: Providing (mostly) security updates for a good phone that fell out of vendor support by using LineageOS for an updated Android system and e.g. the CIP maintained SLTS 4.4 kernel. And I know of at least 2 other devices using the same kernel as they share the platform.
Regards, Alex
On Sun, Jul 10, 2022 at 02:38:15PM +0200, Alexander Grund wrote:
On 10.07.22 13:06, Greg KH wrote:
Make sure the patches you are submitting follows those rules on what is able to be accepted.
Looks like I have to exclude a couple of patches especially due to the 100-lines rule. That especially hits the last one replacing 350 lines initialization code by 6 lines doing the same but avoiding potential errors by missing some initialization.
Submit them and we can see. Deleting code is always good.
Also, please wrap your email lines...
The Civil Infrastructure Platform (CIP) e.g. maintains LTS kernel trees which are now End of Life but still used. They call that SLTS ("Super Long Term Support") and there is e.g. a 4.4.y branch with backports from the 4.9.y LTS branch. That kernel is e.g. used in many Android phones.
What 4.4.y Android devices are still supported by their vendors? And are they still getting kernel updates?
Actually the issue is that those devices are not supported by their vendors anymore, so they may only get updates through LineageOS. That is a third-party Android build where maintainers rely on proprietary binaries from the original phone which are tied to a specific kernel. Hence when the device falls out of support having a 4.4 kernel in the last release there is no way for those maintainers to switch to a newer kernel. That's the situation e.g. I am in right now: Providing (mostly) security updates for a good phone that fell out of vendor support by using LineageOS for an updated Android system and e.g. the CIP maintained SLTS 4.4 kernel. And I know of at least 2 other devices using the same kernel as they share the platform.
All of those devices that wish to keep working should just forward port their tree to newer kernel versions so that they can stay secure and working properly. It is far easier to do that than to attempt to keep older kernel trees alive over time. I've done both in the past and it's always simpler to move forward.
So why not just do that instead of attempting to keep these old kernels alive? Do the effort once and then you can rely on the community's help. Otherwise you are stuck on your own for forever.
thanks,
greg k-h
On 10.07.22 14:48, Greg KH wrote:
What 4.4.y Android devices are still supported by their vendors? And are they still getting kernel updates?
Actually the issue is that those devices are not supported by their vendors anymore, so they may only get updates through LineageOS. That is a third-party Android build where maintainers rely on proprietary binaries from the original phone which are tied to a specific kernel. Hence when the device falls out of support having a 4.4 kernel in the last release there is no way for those maintainers to switch to a newer kernel. That's the situation e.g. I am in right now: Providing (mostly) security updates for a good phone that fell out of vendor support by using LineageOS for an updated Android system and e.g. the CIP maintained SLTS 4.4 kernel. And I know of at least 2 other devices using the same kernel as they share the platform.
All of those devices that wish to keep working should just forward port their tree to newer kernel versions so that they can stay secure and working properly. It is far easier to do that than to attempt to keep older kernel trees alive over time. I've done both in the past and it's always simpler to move forward.
So why not just do that instead of attempting to keep these old kernels alive? Do the effort once and then you can rely on the community's help. Otherwise you are stuck on your own for forever.
Because forward porting is not possible. As mentioned the original device vendor does no longer support those devices so what the community has is a blob of binaries compiled against a specific kernel version with no access to their sources. As those binaries (mostly hardware "drivers") are required to use the device, recompilation isn't possible and they are likely coupled to the kernel version specific API/ABI "we" (me and maintainers of similar devices) have to stick to that kernel. And given that a community supported/maintained 4.4 kernel exists (as a SLTS kernel maintained under CIP) the situation seems to be common.
So I'm already relying on the community's help, CIP in this case. And they rely on the 4.9 stable kernel and suggested that they only accept changes already present in 4.9. So here I am with work I did for a specific 4.4 kernel giving that back to the wider community (4.9 and all downstream kernels).
Alex
On Sun, Jul 10, 2022 at 03:02:52PM +0200, Alexander Grund wrote:
On 10.07.22 14:48, Greg KH wrote:
What 4.4.y Android devices are still supported by their vendors? And are they still getting kernel updates?
Actually the issue is that those devices are not supported by their vendors anymore, so they may only get updates through LineageOS. That is a third-party Android build where maintainers rely on proprietary binaries from the original phone which are tied to a specific kernel. Hence when the device falls out of support having a 4.4 kernel in the last release there is no way for those maintainers to switch to a newer kernel. That's the situation e.g. I am in right now: Providing (mostly) security updates for a good phone that fell out of vendor support by using LineageOS for an updated Android system and e.g. the CIP maintained SLTS 4.4 kernel. And I know of at least 2 other devices using the same kernel as they share the platform.
All of those devices that wish to keep working should just forward port their tree to newer kernel versions so that they can stay secure and working properly. It is far easier to do that than to attempt to keep older kernel trees alive over time. I've done both in the past and it's always simpler to move forward.
So why not just do that instead of attempting to keep these old kernels alive? Do the effort once and then you can rely on the community's help. Otherwise you are stuck on your own for forever.
Because forward porting is not possible. As mentioned the original device vendor does no longer support those devices so what the community has is a blob of binaries compiled against a specific kernel version with no access to their sources.
That's a lovely GPL violation that I am sure those vendors would be glad to fix up and provide the source for. Especially if those vendors are wanting to use newer kernel versions in newer devices :)
As those binaries (mostly hardware "drivers") are required to use the device, recompilation isn't possible and they are likely coupled to the kernel version specific API/ABI "we" (me and maintainers of similar devices) have to stick to that kernel.
If you do not know what sources those blobs are built from, then trying to keep a stable abi is very very difficult, as I know from experience.
Good luck!
greg k-h
linux-stable-mirror@lists.linaro.org
-
Alexander Grund -
Greg KH