Kernel Hardening - security-misc

Good point.

Here is a related bug report:

Summary:

  • Ubuntu seems to harden this already.

Kees Cook (kees) wrote on 2011-04-25: #3

This mode change is “by design”. For local admins that what to relax this restriction, you can use dpkg-statoverride:

sudo dpkg-statoverride --add root root 0644 /boot/vmlinuz-$(uname -r) --update

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?].

Richard W.M. Jones (rich-annexia) wrote on 2011-04-26: #5

What is being protected by this mode change? This kernel is distributed
on hundreds of mirrors – there is no secret in here.

Kees Cook (kees) wrote on 2011-04-26: Re: [Bug 759725] Re: The kernel is no longer readable by non-root users

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.

Kees Cook (kees) wrote on 2011-04-26:

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
  • might break hobbit-plugins (whatever that is)

Richard W.M. Jones (rich-annexia) wrote on 2011-04-26: #8

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.

annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_kallsyms.ml
annexia.org >> repositories - virt-mem.git/blob - lib/virt_mem_ksyms.ml

  • ^ → 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?

  1. create linux group boot (or similarly named?) → Port to sysusers.d mechanism?

sudo chgrp --recursive boot /boot
sudo chmod --recursive o-r /boot
1 Like