kernel security update fails if a 2nd Ubuntu on same machine

[Peter D.]

There is a security issue when multiple instances of Ubuntu (or other distributions) are installed on the same hardware. In my case I have 14.04 LTS and 16.04 alpha (plus some others).

After installing 14.04 LTS as the main system on an UEFI machine there is a file, </boot/efi/EFI/ubuntu/grub.cfg> that effectively points to whichever installation has control of the boot process and which instance of GRUB2 gets run. If a second install, for example, a test of 16.04 alpha, is made then that file is over written.

Rebooting 14.04 LTS via 16.04 alpha's GRUB2 or other means and installing a standard kernel security update does NOT make the new kernel available on subsequent reboots because even though 14.04 LTS's GRUB2 has been updated it is never run. 16.04 alpha's GRUB2 (which is ignorant of 14.04 LTS's update) is run because that is what </boot/efi/EFI/ubuntu/grub.cfg> points to.

There are many ways to fix this problem.

1)
Make all installations maintain a link to the most recent kernel. Ubuntu does this, there are links in the root directory current and old of kernel and intrd. Make all boot loaders look for those links. If Ubuntu configured GRUB2 to look for /vmlinuz it could find the current kernel even if the kernel had been upgraded after GRUB2 was updated. Ubuntu configured GRUB2 does not do this. Of course it is impossible to get all software from all sources to "play nice", but you could make multiple installations of Ubuntu co-operate with each other.

2)
Check where </boot/efi/EFI/ubuntu/grub.cfg> points to and "take it back", if necessary.
Modified </etc/kernel/postinst.d/zz-update-grub> attached.

3)
Use an EFI style boot loader on EFI machines. There is an Ubuntu repository for rEFInd, which has worked well for me. This has the added advantage that if anyone makes a test installation like 16.04 alpha and then deletes it (not an unreasonable thing to do with an alpha release) then the machine does not become unbootable - because </boot/efi/EFI/ubuntu/grub.cfg> would be pointing to an non-existent instance of GRUB2. BTW rEFInd and GRUB2 can be made to co-exist in various way, if you want.

END)

I can not see how to make an attachment to this bug report, so I will paste my zz-update-grub here as text, and ubuntu-bug did not work for me.
<cut-n-paste from terminal>
$ ubuntu-bug linux
usage: whoopsie-upload-all [-h] [-t TIMEOUT]
whoopsie-upload-all: error: unrecognized arguments: linux
<\cut-n-paste from terminal>

<cut-n-paste of my /etc/kernel/postinst.d/zz-update-grub>
#! /bin/sh
set -e

which update-grub >/dev/null 2>&1 || exit 0

if type running-in-container >/dev/null 2>&1 && \
   running-in-container >/dev/null; then
        exit 0
fi

set -- $DEB_MAINT_PARAMS
mode="${1#\'}"
mode="${mode%\'}"
case $0:$mode in
    # Only run on postinst configure and postrm remove, to avoid wasting
    # time by calling update-grub multiple times on upgrade and removal.
    # Also run if we have no DEB_MAINT_PARAMS, in order to work with old
    # kernel packages.
    */postinst.d/*:|*/postinst.d/*:configure|*/postrm.d/*:|*/postrm.d/*:remove)
        CFG1='/boot/efi/EFI/ubuntu/grub.cfg'
        CFG2='/boot/grub/grub.cfg'
        if [ -e $CFG1 ]; then
                # This is an EFI system.
                # Does that config file point to this installation?
                # Get UUID of installation that that file points to
                UUID=$(grep "\<[[:xdigit:]-]\{36\}\>" $CFG1 \
                        | cut --delimiter=' ' --fields=2)
                # Is file format stable?
                # Could use "sed" rather than "cut" to find UUID.
                # UUID=$(sed -n -e 's/^.*\(\<[[:xdigit:]-]\{36\}\>\).*$/\1/p' $CFG1)

                # Get device name for this installation
                # Spaces are needed, in case grub2 is on the root partition.
                DEVICE=$(mount \
                        | grep " $(df --output=target $CFG2 \
                        | tail --lines=1) " \
                        | cut --delimiter=' ' --fields=1)

                # Do they both have the same line in blkid?
                if [ "$(blkid | grep $DEVICE)" \
                        != \
                        "$(blkid | grep $UUID)" ] ;
                then
                        # They do NOT match.
                        # That EFI entry does not point to this installation.
                        # Configuring grub on this installation is pointless.
                        # Options;
                        # hope that the other installation(s) is well configured
                        # (Ubuntu 16.04 alpha is not) AND/OR GETS RUN, or
                        # reINSTALL (not reconfigure) grub2 on this installation.
                        exec grub-install
                fi
                # Fall through, that grubx64.efi file WILL find this installation.
                # Reconfigure only.
        fi
        # Fall through, not evan an EFI system, reconfigure only.
        if [ -e $CFG2 ]; then
                exec update-grub
        fi
        #Fall through, is grub not installed on this system?
        ;;
esac

exit 0
~
~
:set nolist 1,1 All
<\cut-n-paste of my /etc/kernel/postinst.d/zz-update-grub>
---
ApportVersion: 2.19.4-0ubuntu2
Architecture: amd64
CurrentDesktop: XFCE
DistroRelease: Ubuntu 16.04
InstallationDate: Installed on 2016-02-03 (24 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160202)
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 4.4.0-2.16-generic 4.4.0
Tags: xenial
Uname: Linux 4.4.0-2-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True
---
ApportVersion: 2.19.4-0ubuntu2
Architecture: amd64
CurrentDesktop: XFCE
DistroRelease: Ubuntu 16.04
InstallationDate: Installed on 2016-02-03 (31 days ago)
InstallationMedia: Xubuntu 16.04 LTS "Xenial Xerus" - Alpha amd64 (20160202)
Package: grub2 (not installed)
ProcVersionSignature: Ubuntu 4.4.0-2.16-generic 4.4.0
Tags: xenial
Uname: Linux 4.4.0-2-generic x86_64
UpgradeStatus: No upgrade log present (probably fresh install)
UserGroups: adm cdrom dip lpadmin plugdev sambashare sudo
_MarkForUpload: True

[Brad Figg (brad-figg)]

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1544809

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

[Mathieu Trudel-Lapierre (cyphermox)]

Reassigning to grub2, which seems more appropriate at a quick glance. I'll look to reproduce this tomorrow.

[Peter D. (0123peter)]

Sorry for the duplication, but I will attach another copy of the same file. *There is a change! * Spaces have been changed to "not a word" characters "\W" in a grep pattern.

And I can now see what to click to add an attachment. Did I miss that, or does it just not exist during bug report creation? A comment that, "attachments can be made latter" would help. My apologies if such a thing exists but I missed it.

Reply to Brad Figg's automatic script in #1:

$ apport-collect 1544809
You need to run 'sudo apt-get install python-apport' for apport-collect to work.

OK, that's why it didn't work. Installed pyton-apport then,

$ apport-collect 1544809
usage: whoopsie-upload-all [-h] [-t TIMEOUT]
whoopsie-upload-all: error: unrecognized arguments: 1544809

Something else is wrong. Will change the status to "confirmed" as instructed. The logs are unlikely to be of much help in this case.

[Peter D. (0123peter)]

On re-reading, I should open another bug report on apport and mark that one confirmed. It will have to wait a few days.

[Peter D. (0123peter)]

apport information

[Peter D. (0123peter)]

apport information

[Peter D. (0123peter)]

apport information

[Peter D. (0123peter)]

apport information

[Peter D. (0123peter)]

I have done "apport-collect 1544809" more than once, and the bug report is still marked as "incomplete", not that my logs should be particularly relevant to boot loader design.

Changing to "confirmed".