The kernel is no longer readable by non-root users

I'm confirming this, and marking marking it as medium.

It is fairly common practice to boot kvm or qemu with something like:
 kvm -kernel /boot/vmlinuz-$(uname -r)

There are easy workarounds (downloading the kernel and extracting and using it), but they're less than idea.

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/vmlinux-$(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/vmlinux-${version} --update

Sorry, that should be "vmlinuz" not "vmlinux" in the above examples. :)

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

When we install libguestfs, we need to boot using this kernel. What change
do I need to make to libguestfs so that when a sysadmin installs it, it will
change the permissions back to 0644 automatically?

On Tue, Apr 26, 2011 at 11:21:38AM -0000, Richard W.M. Jones wrote:
> What is being protected by this mode change? This kernel is distributed
> on hundreds of mirrors -- there is no secret in here.

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.

> When we install libguestfs, we need to boot using this kernel. What change
> do I need to make to libguestfs so that when a sysadmin installs it, it will
> change the permissions back to 0644 automatically?

Shipping a pair of files in /etc/kernel/postinst.d/ and
/etc/kernel/postrm.d/ to call dpkg-statoverride --add and --remove
respectively is likely the cleanest approach to handling this.

--
Kees Cook
Ubuntu Security Team

On Tue, Apr 26, 2011 at 05:25:33PM -0000, Kees Cook wrote:
> On Tue, Apr 26, 2011 at 11:21:38AM -0000, Richard W.M. Jones wrote:
> > What is being protected by this mode change? This kernel is distributed
> > on hundreds of mirrors -- there is no secret in here.
>
> 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.

This non-root user that we imagine has no access to the world
wide web? This is absolutely nuts, sorry.

Rich.

--
Richard Jones
Red Hat

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.

http://git.annexia.org/?p=virt-mem.git;a=blob;f=lib/virt_mem_kallsyms.ml;h=9e6eccb6629a2ea067ee46a7c690aea17e44c0d2;hb=HEAD#l39
http://git.annexia.org/?p=virt-mem.git;a=blob;f=lib/virt_mem_ksyms.ml;h=8a38caec5b9fa05904c3b9e8b5fcdb76871f27ae;hb=HEAD#l29

I recognize this can get in some people's way, which is why I've tried to demonstrate how to adjust the local system to retain the more open permissions.

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.

The postinst.d and prerm.d solution should provide a reasonable work-around for the small number of systems that need it.

On Tue, Apr 26, 2011 at 09:49:25PM -0000, Kees Cook wrote:
> 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.

You didn't appear to understand the code that I wrote: it gets out the
symbols from any version of the kernel by simply reading the kernel
*runtime memory*.

So the attacker now has two alternative methods: (a) fire up a web
browser or (b) inject shell code into the kernel which greps through
physical memory to find the symbol tables, and note method (b) works
with any kernel version without reference to the original vmlinuz
file.

> It changes the nature of future attacks, at least forcing attackers
> to take additional steps.

Yes, firing up a web browser or injecting an extra small piece of
shell code into the kernel.

I need to mount a binary file that contains a filesystem so I can copy files onto it.

I could already do this using /dev/loop but I need to automate this without requiring root privileges for a build system.

To solve this problem, the guestmount folks pulled together TONS of code. They are creating a custom minimized kernel, emulating it with QEMU, booting it with the binary file attached, attaching FUSE to the mount point and connecting to it at the application layer. All to avoid needing /dev/loop and root access.

Guestmount used to work out of the box. And you just broke it "by-design" with a change that provides zero security or protection from anyone with a brain or an internet connection. I agree with Rich W. M. Jones. You are making ubuntu less useful.

Since the vmlinuz-X.WY.Z-X-generic can be easily downloaded from the Internet, this "by design" change makes Ubuntu less useful.

Ubuntu needs to make "IT things" (Linux) better for humans, not worse... :-/

This is also afecting OpenStack... Reference: http://docs.openstack.org/icehouse/install-guide/install/apt/content/nova-compute.html

This also affects monitoring tools like e.g. the libs test in hobbit-plugins which compare the running kernel version to the one on disk. These tests don't run as root as they don't need to. Now they need elevated privileges just do this check... :-/

Status changed to 'Confirmed' because the bug affects multiple users.

Is it possible to change vmlinuz permissions so it's readable by members of special group (libguestfs)?.
This way admins could locally fix this "by design" stupidity easily for affected users instead of forcing maintainers for all the affected packages to supply statoverride scripts.

I changed the following under Ubuntu 14.10:
File /usr/lib/xymon/client/ext/libs
69c69
< my $kernel_image_read_command = "strings '$newest_kernel_image'";
---
> my $kernel_image_read_command = "$SUDO strings '$newest_kernel_image'";

ext$ ./libs
strings: /boot/vmlinuz-3.16.0-23-generic: Permission denied
status unknown.libs yellow Tue Oct 28 09:30:03 2014 - libs NOT ok
&yellow Kernel image /boot/vmlinuz-3.16.0-23-generic unreadable. Can't check kernel version!

ext$ ./libs_patched
BFD: /boot/vmlinuz-3.16.0-23-generic: Warning: Ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .bss
status unknown.libs yellow Tue Oct 28 09:30:09 2014 - libs NOT ok
&green Newest kernel is running: 3.16.0-23-generic, version #31-Ubuntu SMP Tue Oct 21 17:56:17 UTC 2014

This works only if started the ./libs localy, but not via xymonclient. There I got the error "sudo: no tty present and no askpass program specified", but I don't know how to adapt it, that it works also with the xymonclient.

Any news on this?

As of 15.04 this embarrassing security theatre is still in place.

The correct override command is:

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

Why guestmount can't work out of box? That was a perfect userspace option to get a loop device to test out-of-space errors.

Does this mean there is now no non-root way to extract files from filesystem images?

$ sudo dpkg-statoverride --add root root 0644 /boot/vmlinux-$(uname -r)
dpkg-statoverride: error: --add needs four arguments

only updated for a single kernel, and apparently not the one virt-make-fs is using.

I then did:

sudo chmod +r /boot/vmlinuz-*

and virt-make-fs was happy.

A consequence of the design decision to prevent read-access for users is that a bug has emerged in libguestfs: https://bugs.launchpad.net/ubuntu/+source/libguestfs/+bug/1813662

Would it be possible to make the kernel readable by a special group (i.e. "kernel-readers"), which Ubuntu-distros could have installed by default?

In this case it would suffice to make users member of this group, if they want to use tools that need kernel read access.

Or would that somehow violate the Ubuntu maintainers sense of safety, too?

This forces us to run tftpd as root, to serve $CHROOT/boot to netboot clients,
so it's actually LESS secure than it was before the change.

Applying the stat workaround isn't always easy; sometimes $CHROOT/boot comes from a read-only loopback image.

Also note that initrd.img, which may actually contain private information, is world-readable.

Very disappointed to see this is marked as 'Wont fix'. It is pointless security theatre and is breaking useful things. In my case it is libguestfs. Please reconsider

ROLL BACK THIS DAMN CHANGE!!!

Fortunately, you can still get the current kernel quite easily:

curl $(python3 -c "import apt, os; print(apt.cache.Cache()['linux-image-' + os.uname().release].versions[0].uri)") | dpkg-deb -x - .

On Focal the correct command to (temporarily) fix the permission problem:

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

However, I also feel that that making non secret information world readable would have been the Unix way. This change made the life of a few script kiddies a very bit harder, but also made the life of many legal users significantly harder (in contrast with a script kiddy they have to maintain the fix in a more formalized way).

this actually make ubuntu much insecure because you have to run most tools with sudo and normally those tools recommend user NOT to run it with root. Other distros are still readable by normal user and they harden it via selinux.

Trying to understand the process here. This change affects multiple people and projects, has no real rationale, worsens security, and is trivial to fix. Why is it still there? How do we escalate this past this Kees Cook's misplaced stubbornness?

I'm still trying to reliably workaround this pointless bug. It seems one needs to create a script in /etc/kernel/postinst.d to run dpkg-stateoveride --update, but that command is not idempotent, so kernel updates fail if you update existing versions.

Looks like this workaround is working for me as new kernel versions are released:

    $ cat /etc/kernel/postinst.d/statoverride
    #!/bin/sh
    version="$1"
    [ -z "${version}" ] && exit 0
    dpkg-statoverride --update --add root root 0644 /boot/vmlinuz-${version}

That file must be executable.

The "statoverride" script appears to work on the first run for each kernel. However, any subsequent times the `dpkg-statoverride` command exits with errorcode 2:

    $ apt-get install something-triggering-dkms

    Processing triggers for linux-image-5.4.0-96-generic (5.4.0-96.109) ...
    /etc/kernel/postinst.d/dkms:
     * dkms: running auto installation service for kernel 5.4.0-96-generic
       ...done.
    /etc/kernel/postinst.d/initramfs-tools:
    update-initramfs: Generating /boot/initrd.img-5.4.0-96-generic
    /etc/kernel/postinst.d/statoverride:
    dpkg-statoverride: error: an override for '/boot/vmlinuz-5.4.0-96-generic' already exists; aborting
    run-parts: /etc/kernel/postinst.d/statoverride exited with return code 2
    dpkg: error processing package linux-image-5.4.0-96-generic (--configure):
     installed linux-image-5.4.0-96-generic package post-installation script subprocess returned error exit status 1
    Errors were encountered while processing:
     linux-image-5.4.0-96-generic

    E: Sub-process /usr/bin/dpkg returned an error code (1)

Adding the `--force-statoverride-add` flag fixed the issue:

    #!/bin/sh

    # https://bugs.launchpad.net/ubuntu/+source/linux/+bug/759725

    set -e
    version="$1"
    if [ -z "$version" ]; then
        exit 0
    fi
    exec dpkg-statoverride --force-statoverride-add --update --add root root 0644 "/boot/vmlinuz-${version}"

After that change, now the kernel dkms trigger succeeds:

    Setting up linux-image-5.4.0-96-generic (5.4.0-96.109) ...
    Processing triggers for linux-image-5.4.0-96-generic (5.4.0-96.109) ...
    /etc/kernel/postinst.d/dkms:
     * dkms: running auto installation service for kernel 5.4.0-96-generic
       ...done.
    /etc/kernel/postinst.d/initramfs-tools:
    update-initramfs: Generating /boot/initrd.img-5.4.0-96-generic
    /etc/kernel/postinst.d/statoverride:
    dpkg-statoverride: warning: an override for '/boot/vmlinuz-5.4.0-96-generic' already exists, but --force specified so will be ignored
    /etc/kernel/postinst.d/zz-update-grub:
    Sourcing file `/etc/default/grub'
    Sourcing file `/etc/default/grub.d/init-select.cfg'
    Generating grub configuration file ...
    Found linux image: /boot/vmlinuz-5.4.0-96-generic
    Found initrd image: /boot/initrd.img-5.4.0-96-generic
    Found linux image: /boot/vmlinuz-5.4.0-94-generic
    Found initrd image: /boot/initrd.img-5.4.0-94-generic
    Found linux image: /boot/vmlinuz-5.4.0-91-generic
    Found initrd image: /boot/initrd.img-5.4.0-91-generic
    Found memtest86+ image: /boot/memtest86+.elf
    Found memtest86+ image: /boot/memtest86+.bin
    Found Ubuntu 20.04.3 LTS (20.04) on /dev/md126p1
    done

If this is to be added as a postinst.d to the libguestfs-tools package, please don't forget the `--force-statoverride-add` flag... or else we introduce a new dkms / kernel postinst.d trigger idempotency bug.