[haiku-development] Re: Design for signed packages
- From: Ingo Weinhold <ingo_weinhold@xxxxxx>
- To: haiku-development@xxxxxxxxxxxxx
- Date: Tue, 25 Mar 2014 21:55:34 +0100
On 25.03.2014 13:41, Jonathan Schleifer wrote:
Am 25.03.2014 um 06:53 schrieb Ingo Weinhold <ingo_weinhold@xxxxxx>:
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 ;).
That's why unpackaged executables would have to be signed.
Then an attacker just places a shell script with shebang. And now? Do
you want to sign shell scripts, too?
Sure.
Again, if only signed code is executed, you can always boot from an
off state into a trusted system (or the system won't boot, in which
case you do at least know that it has been compromised).
Well, we see how well that works with the iPhone. It only executes
signed code since it's launch, yet even today, there are still
jailbreaks ;).
That only demonstrates that there's no absolute security.
Secure boot plus executing only signed code makes exploits harder.
The problem with the shell scripts remains. And the problem that
programs load code from e.g. libraries,
Libraries are executable code, so they would need to be signed.
can interpret scripts, etc.
and run as root, thus can even access /dev/misc/mem.
Scripting language interpreters would have to support restricting
execution to signed code as well.
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.
The thing is that it is superfluous for this purpose, since there
more effective means to do that.
What can be more effective? Setting a firmware password? Won't help
if you have a notebook where it only takes 2 screws to get out the
hard disk.
(Unfortunately even Lenovo makes switching the disk rather hard these
days. :-/ But that's another topic.)
Yes, firmware password plus disk encryption.
Again, no one needs Secure Boot for that purpose. Unless you
encrypt your disk, an attacker can just remove the disk from your
system, put it in a system they control, and manipulate it freely.
So no, Secure Boot does not help you in this respect. Disk
encryption does.
Disk encryption alone doesn't help you either, because the bootloader
can simply be swapped. The combination of both is what helps.
TBH, I was under the impression that UEFI already supported disk
encryption, so that there wasn't a gap. But apparently that isn't the
case, unfortunately. So, you're right Secure Boot would need to be
supported. But not by the OS, just by the decrypting boot loader.
As written above, Secure Boot cannot eliminate that threat, but
together with only executing signed code it can help reduce it. It
is one thing for a browser exploit to write a file to the
auto-start or kernel modules directory, it is another to get that
code to be executed. It's the latter that can be made harder.
If it can write a file to the auto start or kernel modules directory,
what's preventing it from simply installing a new certificate as
well?
That's a good point. I guess one would have to be more restrictive and
only accept certificates of a certificate chain anchored by a
certificate built into the kernel.
Anyway, it seems to me that to get a significant benefit out of
supporting Secure Boot one would have to go to great length. I'm less
and less convinced that it is worthwhile to consider it at all. And with
it making package signing anything more than an optional feature mainly
targeted at third parties.
CU, Ingo
Other related posts:
