CONFIG_KFENCE is a Low-Overhead Memory Safety Feature introduced in Linux 5.12 that is more competent than the KASAN. Used for uncovering similar out-of-bounds / use-after-free / invalid-free errors but with no overhead.
hi a different function and greater security
some guys shared a topic : firejail / seccomp / More Options for Program Containment
there is a security patch Landlock : Landlock: unprivileged access control
CONFIG_SECURITY_LANDLOCK=y
tried a sandbox inside another sandbox ./landlock1 /bin/sh firejail *application
With the exploits and bypasses that there are lately,
I believe that greater security is necessary
Theory : Apparmor > Landlock > Firejail > Tor browser
When it does land in mainline, it will be a very long time before it reaches LTS and besides, I don’t see a significant advantage of this over AppArmor + bubblewrap. Landlock is intended for use cases in which the user does not have the adminstrator privileges necessary to configure traditional security policies like AppArmor which does not apply to us.
Combining a whole bunch of different access control mechanisms would be redundant — it’s the same kernel enforcing all of these policies and a single kernel exploit can bypass all of them. Unless Landlock exposes the ability to restrict something that isn’t already covered by our current approach, I don’t see an advantage.
The Landlock LSM is now mainlined in 5.13. I wonder if it can be stacked wit the app sandbox we are working on since it too can restrict unprivileged apps.
Installed the Whonix hardened kernel on another distro and now some systemd services will not start. Don’t seem to be able to restart these services and when sudo systemctl start [service] is run, there is an error message which is described as exit-code. Also commands to the dbus seem to fail as well, returning
Failed to connect to bus: Connection Refused
Bunch of upcoming changes to spectre protection defaults and build time compiler options added to newer releases of LLVM and GCC. Sending pulls to other Linux projects may be helpful:
Difficult to understand what these changes do. A comment from the discussion thread frames it this way:
The question is, which programs in the past have opted in with PRCTL? Which in the future will be SECCOMP threads which will have it applied?
"The paper points to AMD CPUs suffering from a side-channel leakage vulnerability through timing and power variations of the PREFETCH instruction. The paper argues that AMD CPUs should activate stronger page table isolation by default. "
“With the Linux kernel already supporting Kernel Page Table Isolation albeit not enabled by default on AMD CPUs, it’s easy to test the behavior otherwise. KPTI can already be forced on for AMD CPUs under Linux if booting with the “pti=on” kernel option (not to be confused with the “kpti=1” option that is for controlling page table isolation for AArch64 systems, unfortunately through a different knob).”
Slipping under our radar earlier this month was that GCC 12 has landed stack variable auto-initialization. This new GCC 12 security feature can be turned on with the “-ftrivial-auto-var-init=zero” compiler switch. LLVM/Clang saw this security option posted back in 2018."
I don;t know why they thought it was a good idea to include an in-kernel SMB3 file server that turned up vulnerabilities, but I’m sure we are all better off without it. This is a Linux 5.15 “feature” that we can turn off.
