Re: [RFC] Second attempt at kernel secure boot support

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/31/2012 01:08 PM, Alan Cox wrote:
On Wed, 31 Oct 2012 15:56:35 +0000
Matthew Garrett <mjg59@xxxxxxxxxxxxx> wrote:

1) Gain root.
2) Modify swap partition directly.
3) Force reboot.
4) Win.

Root should not have the ability to elevate themselves to running
arbitrary kernel code. Therefore, the above attack needs to be
impossible.
To protect swap you need to basically disallow any unencrypted swap (as
he OS can't prove any given swap device is local and inside the case) and
disallow the use of most disk management tools (so you'll need to write a
few new management interfaces or implement the BPF based command filters
that have been discussed for years).

Can any kernel memory get swapped? If not all root can do is mess with the memory of other userspace processes, which isn't a use-case that secure boot cares about from my understanding.

In addition of course there is no requirement that a device returns
the data you put on it so subverted removable media is a potential issue.
Or indeed just cheap memory sticks that do it anyway ;)

Oh and of course the file systems in default mode don't guarantee this so
you'll need to fix ext3, ext4 8)

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

--
To unsubscribe from this list: send the line "unsubscribe linux-efi" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux