Open kees opened 4 years ago
kees
commented
3 years ago Specifically, the plan Linus seemed to like was detailed at this point in the thread: https://lore.kernel.org/kernel-hardening/CAGXu5jJQnokKL2MdbQgOhBJ_RMHVvsw4u27Ds=4Jq3Ys=mjtRg@mail.gmail.com/
kees
commented
2 years ago Global sysctl for user namespaces: https://lore.kernel.org/lkml/20220809185229.28417-1-vegard.nossum@oracle.com
kees
commented
1 year ago kees
commented
1 year ago Refresh of sysctl proposal: https://lore.kernel.org/lkml/20230112131911.7684-1-vegard.nossum@oracle.com/
Continue the work to limit the way modules are autoloaded by the kernel:
https://lore.kernel.org/kernel-hardening/1511803118-2552-1-git-send-email-tixxdz@gmail.com/
To quote the cover letter:
Currently, an explicit call to load or unload kernel modules require CAP_SYS_MODULE capability. However unprivileged users have always been able to load some modules using the implicit auto-load operation. An automatic module loading happens when programs request a kernel feature from a module that is not loaded. In order to satisfy userspace, the kernel then automatically load all these required modules.
Historically, the kernel was always able to automatically load modules if they are not blacklisted. This is one of the most important and transparent operations of Linux, it allows to provide numerous other features as they are needed which is crucial for a better user experience. However, as Linux is popular now and used for different appliances some of these may need to control such operations. For such systems, recent needs showed that in some cases allowing to control automatic module loading is as important as the operation itself. Restricting unprivileged programs or attackers that abuse this feature to load unused modules or modules that contain bugs is a significant security measure.
This allows administrators or some special programs to have the appropriate time to update and deny module autoloading in advance, then blacklist the corresponding ones. Not doing so may affect the global state of the machine, especially containers where some apps are moved from one context to another and not having such mechanisms may allow to expose and exploit the vulnerable parts to escape the container sandbox.