2

Background: We're developing for a Debian 9.8 system on an x86, but most of us here are more used to dealing with embedded devices.

according to wikipedia, secure boot can "secure the boot process by preventing the loading of drivers or OS loaders that are not signed with an acceptable digital signature". I take this to mean that kernel-level code is protected, but that user-level code is not.

I am having some terminology confusion with my boss, who is under the impression that Secure Boot can protect the entire system. I believe that Secure Boot can secure the entire system only when the computer-in-question is an embedded device (you will never receive software updates, therefore you can group all the executable stuff together and sign that). If the device is your typical PC, secure boot cannot practically keep it secure (your PC is getting software updates all the time, meaning that an executable block would be changing all the time, meaning that you'd have to recalculate/re-sign the entire block with each update).

Am I right, or is he? Is there an easy way to extend the protections of Secure Boot to our custom user-level software? Is there something similar to secure boot that I should be looking at to secure user-level software?

user1733212
  • 21
  • 2
  • The short answer is that secure boot only secures the kernel, as you said, and will only work for signed kernels. – Steve Sether Sep 10 '19 at 19:07
  • 1
    For signed binaries, you might look at this answer: https://security.stackexchange.com/questions/138651/does-linux-support-signed-binaries – Steve Sether Sep 10 '19 at 19:11

3 Answers3

0

Your boss is mistaken I'm afraid. Here's how it works in Windows

  1. Secure boot secures the bootloader
  2. Trusted boot then takes over to load the kernel
  3. ELAM takes over to load the drivers
  4. Measured boot finishes off the process

So each stage secures the next one, each of which is performing more complex actions, which makes sense, you want anything security related to be as minimal as possible to make it easy to reason about. Once you are past the boot process, Windows Defender is the main mechanism for protection.

This is how it works when your PC is getting software updates all the time. But all the layers are required to protect the entire operating system as your boss wants.

I am pretty familiar with Debian but I'm not aware that it can do layering like this. I protect Debian systems in userspace with AppArmor.

Gaius
  • 810
  • 6
  • 7
  • OP said "but the space in which we are operating is dominated by embedded devices." so, IMHO, the example given (secure boot in windows) is off topic. – binarym Sep 10 '19 at 07:54
  • Reading a bit into AppArmor, it seems to function like SELinux. I'm only a little familiar with SELinux, but I'm not sure how I would use AppArmor to prevent one of my processes from clobbering another. Can I use AppArmor to make sure that no matter what one process does, it can't leave its sandbox? The intent here is to prevent corruption of our user level software by a bad actor who has the (very temporary) ability to talk to one of our services over a Bluetooth link. – user1733212 Sep 10 '19 at 18:09
  • AppArmor is far better that SELinux IMHO, it does everything you need and is much simpler to set up. Basically you can whitelist what any process can do and AppArmor will block absolutely everything that isn’t on that list – Gaius Sep 11 '19 at 08:00
  • @binarym the OP requested clarification of the scope of Secure Boot so that’s what I wrote – Gaius Sep 11 '19 at 08:02
  • @gaius agreed. See my other comment below on this page (after OP told target device is a PC) – binarym Sep 11 '19 at 09:54
0

if I understand your question correctly, your intent of the question to know how to secure applications/binaries in the filesystem assuming that secure boot took care of securing the boot process.

Essentially you are looking for a way to validate the integrity of binaries on your filesystem, you could achieve this by enforcing integrity check on a periodic basis and post system upgrade, etc.

I've come across embedded devices which do secure boot, integrity check of blocks and integrity checks on binaries as well.

Deadsh0t
  • 11
  • 1
  • Yes, you're parsing the thrust of my question correctly. What you suggest is essentially what I would do if I needed to invent a solution myself... what I am hoping for is a COTS solution from Debian that I can pull in without too much trouble. – user1733212 Sep 10 '19 at 18:16
  • @user1733212 One such solution is authenticated encryption which is supported by cryptsetup and dm-crypt. I mean authenticating the whole root file system that contains kernel modules and executable files. This may be an overkill since it also contains home directories, music, and movies which you likely don't need to authenticate. – beroal Oct 17 '21 at 15:33
-1

Given my experience working on embedded (and secured) devices, i can tell you that, usually, the following scheme is applied:

  • Bootloader is a "secured one", which mean that it will only allow booting a signed kernel.

  • Bootloader may also assume the role of:

    • Checking the integrity of the root filesystem (signature).
    • If encrypted, decipher it.
    • Load it to a given address in RAM that is then provided to the kernel.

So, depending on the scheme choosen for your system (and even if it is not the primary goal of the secure bootloader), a secure boot can be a way to secure the whole system. Note that your rootfs have to be really optimised to be small.

On my company, bootloader is developed internally so that we can implement what we want into it. The keys used for signature verification are stored in a One Time Programmable memory (OTP), which mean an attacker can't change it.

The same behaviour and level of security is quite difficult to reach with a standard PC computer.

For more information regarding this topic, i would advise you having a look at secure boot on ARM architecture. Secure boot for Windows is quite off-topic for embedded devices...

binarym
  • 744
  • 4
  • 8
  • O.o Is this forum only intended for windows computers? I had assumed it was agnostic. i should clarify the background comment come. By 'space', I mean industry space, i.e. most of the time we're thinking about embedded devices. This particular device is an x86, not an ARM. I'm under the impression that ARMs vary wildly in their capabilities, so I see the potential for confusion... suffice it to say, we are more-or-less writing for a desktop. – user1733212 Sep 10 '19 at 18:12
  • Sorry for misunderstanding (but wikipedia quite agree with me: https://en.wikipedia.org/wiki/Embedded_system). Nevertheless, yeah, if you use regular PC, then @Gaius answer is more relevant than mine. And yeah, unfortunately, because of its open design, making a secure boot on PC is a painfull task... – binarym Sep 10 '19 at 18:56