init_on_alloc=1 makes the kernel initialize newly allocated pages and heap objects with zeroes.
init_on_free=1 makes the kernel initialize freed pages and heap objects with zeroes upon their deletion. This helps to ensure sensitive data doesn’t leak via use-after-free accesses.
I am not sure what the difference between init_on_free=1 and page_poison=1 is. They seem to do the same.
The link above says
If either SLUB poisoning or page poisoning is enabled, we disable
init_on_alloc and init_on_free so that initialization doesn’t interfere
with debugging.
And yes, as Kees and Daniel mentioned, it’s definitely not just dmesg. In fact, the primary things tend to be /proc and /sys, not dmesg itself.
Another example of this would be commit 31b0b385f69d (“nf_conntrack: avoid kernel pointer value leak in slab name”), where the fact that the slab name had a pointer in it leaked it in the filenames in /sys, because we export slab statistics under /sys/kernel/slab/. And each file was readable only by root, but the file names were readable by everybody.
The full system apparmor profile gives fine-grained access to /sys and /proc so that would make kernel pointer leaks very unlikely.
To have this automatically happen with each new kernel, create /etc/kernel/postinst.d/statoverride:
.
#!/bin/sh
version="$1"
# passing the kernel version is required
[ -z "${version}" ] && exit 0
dpkg-statoverride --add root root 0644 /boot/vmlinuz-${version} --update
breaks some KVM use cases
It is fairly common practice to boot kvm or qemu with something like:
kvm -kernel /boot/vmlinuz-$(uname -r)
It might break simpler malware relying on this. It wouldn’t break more sophisticated malware - for that we couldn’t use a public kernel image - kernel would have to be (automatically) re-compiled at user’s machine (kernel recompilation for better hardening) ([+ have different entry / kernel symbol locations, of course. If we’re unlucky, the user would reproducible compile the very same kernel?].
The mode changes do not protect a system from any dedicated attacker (for
the reason you state), but it does have real-world benefits against
simplistic kernel exploitation (keeping kernel symbols away from non-root
users). It is absolutely a trade-off.
I am not saying they’re hidden from being looked up externally (just fetching the kernel package’s System.map file is easiest). But because the symbols can be extracted in the way you point out is why the kernel image itself needs to be unreadable. This change is to block the class of attacks carried out by script kiddies and automated systems that expect to be able to look up symbols locally and make exploits totally portable to all kernel versions. It changes the nature of future attacks, at least forcing attackers to take additional steps.
might break guestmount / libguestfs
might affect OpenStack
might break tftpd serving /boot to netboot clients
By the way, I myself actually wrote code that walks through the kernel memory
finding the location of the symbols. You’re not gaining any extra security by
making this change, but you are making Ubuntu less useful.
^ → User should not have access to /proc/kallsyms too? Doable? Any side effects? Then we can protect from above enumeration too.
I would go as far as saying that non-root users by default shouldn’t be able to read any file in /boot? Let’s use dpkg-statoverwrite or something to restrict access so only members of linux group boot can read it?
Those only seem to be for the host so won’t apply to Whonix VMs.
Not needed. kernel.kptr_restrict=2 already fixes this exact issue. Run cat /proc/kallsyms and you’ll see all addresses have been replaced with 0000000000000000.
Should be sufficient in the security-misc postinst script. If “others” aren’t allowed to read /boot and if only members of group “boot” and root can read /boot, I doesn’t have to be reapplied again and again. Could be protected by a do_once status file to allow easier customization (undo by sysadmin).
If we must. If not avoidable through more efficient / appropriate solution. That script runs a lot. Could slow down performance. Would require multiple status _done files.
The idea of the _done file to do this one once and then don’t bother the sysadmin with it anymore.
More error prone. This might work now (untested) but could break as distribution change things. Better to just run the commands to set the right permissions.
It’s already configurable though sudo pam-auth-update (then disable permission lockdown by security-misc) if someone ever asks about it. Not sure further configurability is required.
My thinking maybe was: permission-lockdown cannot run only at postinst - since during build time, no /home/user folder exists. It is created during first login using pam mkhomedir.
Perhaps permission-lockdown could
run at postinst to lockdown existing user’s home folders.
And then pam mkhomedir with umask= parameter could create new home folders (at first boot time) with already locked down permissions.
(locked down meaning: “others” cannot read. Not “world” readable.)
However, for purposes of locking down /boot, I think that is perfectly doable from security-misc postinst?
I meant allowing people to choose to disable/enable /home, /boot etc. restrictions (once they’re added) as they wish.
I would prefer to have something periodically check and restrict /boot in case the permissions get changed for whatever reason. If a user wants to have the permissions changed, they can disable permission-lockdown (or change specific settings like I said above).
Since it’s only done once (and by the time they want to change the setting that setting is already turned on), it’s even easier for them to just change the permissions back to what they want. Thanks to the _done file, the sysadmin won’t be bothered with this ever again.
Why would anything package work on permissions on folder /boot directly? Or what else could change it?
Even if permissions for things inside folder /boot/something change (Debian deciding to change permissions for kernel image or something), that file would stay inaccessible since the root of the folder (i.e. /boot) already has the correct permissions.
If it should be something more periodic…More enforcing…
(Yet configureable. (?))
(And “non-opaque”.)
What about systemd’s /usr/lib/tmpfiles.d mechanism? Also looks quite appropriate?
(No, not just temp files. Yes, some files there configure permissions for persistent folders such as /var/log or /var/cache.)
Would that work?
the easy profile has a focus on ease of use where more program features work out of the box without the user having to intervene. It also means that there is a larger security attack surface. It can be used for typical single user desktop systems when usability is favored over stricter security.
the secure profile is more security oriented and disables certain program privileges. This can result in some program features not being available or behaving less conventiently. It can be used for typical server or multi-user host machines.
the paranoid profile is a tightly locked down set of settings that isn’t fully usable in production, because a lot of program features will stop working. This should only be used when security is the major requirement and when you are willing to tune the profile into a state where you can perform the task you want to fullfill with the system.
I can’t find the permissions file anywhere online to see what they do. I’ll setup a VM to check.