[haiku-development] Re: Design for signed packages
- From: Jonathan Schleifer <js-haiku-development@xxxxxxxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 25 Mar 2014 01:57:55 +0100
Am 24.03.2014 um 21:27 schrieb Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
> On 03/24/2014 07:55 PM, Jonathan Schleifer wrote:
>> Am 23.03.2014 um 23:17 schrieb Axel Dörfler <axeld@xxxxxxxxxxxxxxxx>:
>>> I don't think we should only support secure boot in combination with an
>>> encrypted boot disk.
>> Well, for it to actually make sense, full disk encryption is basically a
>> must.
>> An attacker can just place arbitrary binaries on the system to get control.
>
> How so? If the boot loader is signed, and loads a signed kernel which loads
> signed packages, I don't quite see how encryption is a necessity.
Just place a binary in non-packaged/bin with a name that clashes with that of
an installed package, e.g. python. Wait until the victim boots and starts
something using python. Let your binary add a new certificate and replace
hpkgs. Attack successful ;).
>> When the system is running, an attacker already needs to be inside the
>> system to place binaries. So it's game over anyway.
>
> It's not. If you have a trusted chain of signed packages, you can make sure
> the system is as clean as its gets.
How? If an attacker's already in the system, it's too late. All you can do is
check your certificate store, remove anything fishy and check if the installed
hpkgs still have the correct signature. And then what? An attacker could still
have placed malicious code somewhere. If he got into the system, he could maybe
even get into the system the same way again. He could install plugins that get
loaded all over the place. For all you know, he had full access and could have
installed a root kit, so that you just can't find it.
> Not really. Windows signs its kernel, and kernel modules. So those are safe.
> If they had the means to secure the userland as well, it could be completely
> safe.
I'm not sure about Windows, but e.g. in Linux, you can AFAIK still access
/dev/mem as root. I wouldn't be surprised if the same works on Windows. For all
you know, the kernel could have been exploited and the whole system moved to a
VM and you won't notice. SecureBoot only secures one thing, the thing already
in it's name: The boot. Everything after that, it can't really secure ;). It
helps to prevent attacks where an attacker gets physical access to your
hardware and wants to plant a backdoor to retrieve some data (e.g. like when
they take your notebook on an airport).
> That's actually up to the implementation.
It could be theoretically done, but trying to secure the running system is
kinda hard. If you can load a kernel module or exploit the kernel, it's game
over. It's much harder to protect the running system than a shut down system. A
shut down system can be protected quite well by SecureBoot.
>> There is no way to prevent them with ports like Firewire, ExpressCard or
>> Thunderbolt: They all allow accessing physical
>> memory directly, without the OS noticing.
>
> This all requires physical access to your system. The probability of that is
> pretty much zero for pretty much everyone on this world (unless you are an
> ATM machine). I personally don't see a need to waste time on such a solution.
Yes, so does writing files to the hard drive. The situations where SecureBoot
helps is leaving your hardware unattended for some amount and of time and shut
off. E.g. nobody at an airport can install malware like some states seem to do
(some even suggest "go into the country with an empty hard drive and come back
with an empty hard drive). It also prevents someone sticking a USB stick into
your system and infecting it. As long as it's not running, not much can be done.
> The threat that is real for everyone is online.
Yes, but secure boot is not about preventing that thread. That thread needs to
be prevented purely by the OS itself. Speaking about which, we could start by
looking into having policies for executables (similar to CAPSICUM maybe), as
that might be easier than porting stuff to non-root that were always designed
to be run as root.
--
Jonathan
Other related posts:
