But, I am a bit confused, this guides signs vmlinuz, but not a single
Don´t the kernel modules need to be signed as well?
Or is there some magic that applies the vmlinuz signature automatically
to all modules?!
Last, there is a UEFI boot entry "opensuse-trusted" (or similar), I
guess this is meant to use with secure boot / shim?
On 29/03/17 07:04 AM, Malte Gell wrote:
> But, I am a bit confused, this guides signs vmlinuz, but not a single
> Don´t the kernel modules need to be signed as well?
> Or is there some magic that applies the vmlinuz signature automatically
> to all modules?!
Personally I think that an signed boot is meaningless,
Without, that is, an encrypted root, swap, home and all other data.
Encrypt your drive and be done with it.
Why do I think that a signed boot is meaningless?
Well if I have access to your machine for more than a trivial amount to time I
can be off with it or off with its hard drive or an image of the drive.
I don't have to be an uber-hacker to do any of that.
Once I have your drive I can mount it on another machine, and at that point I'm
not going to be after your kernel or modules when I can get at your data.
If its a laptop, well, there are uncounted stories of laptops being stolen.
And the moment you get off a plane a ship or in many cases cross a
jurisdictional boundary your laptop may be subject to inspection and perhaps
imaging. That's not a situation which is getting any easier for travellers.
I've been fortunate in that no place I've worked has had a break-in where the
thief simply took the desktops or the drives from the desktop, but I've read of
that happening. However one of my clients had a contractor that did not
adequately sanitize the drives of EOL desktops that were being disposed of.
This seems common; the discards that I find stacked in the Closet of Anxieties
don't have wiped hard drives, but at least they haven't left the premises.
I would strongly advocate encrypting the hard drive.
Encrypted/protected boot or simply encrypted root is not adequate.
Yes, its nice to protect the /etc/passwd with additional layers, but how
meaningful is it? There are much more effective ways of getting passwords (or
bypassing access controls) than attacking a Linux /etc/passwd file.
What counts is DATA. Protect your web site data, especially when the web site
is active :-) Protect your user's data under /home. Protect your databases.
Look, if you are really concerned you should have each user's $HOME in a
separate container that is unlocked and mounted when and only when they are
logged in by using an appropriate PAM module and their own cryptographic signature.
Stop and think about it; do a proper risk analysis. Consider where your really
valuable resources are. Consider your actual vulnerabilities and rate them.
There's the old story about the drunk looking for his lost keys under the lap
post because the light is better there, never mind that he lost his keys
somewhere else. sadly, too much of 'protection' is like that. What actual
protection does a 'secure boot' bring when compared to, say, an encrypted drive,
and how complex are each to implement?
The first method for estimating the intelligence of a ruler is to look at the
men he has around him.
To unsubscribe, e-mail: [hidden email] To contact the owner, e-mail: [hidden email]
Am 29.03.2017 um 18:14 schrieb [hidden email]:
> On Wed, Mar 29, 2017 at 01:04:46PM +0200, Malte Gell wrote:
>> to bring pain to a new level I play with secure boot and want to get a
>> custom kernel run with secure boot. I read the SUSE how to from there:
>> https://en.opensuse.org/openSUSE:UEFI#Booting_a_custom_kernel >>
>> But, I am a bit confused, this guides signs vmlinuz, but not a single
>> Don´t the kernel modules need to be signed as well?
> For openSUSE kernels module loading is not restricted (for SLES it is)
Ok. I think this is no problem, there still is MODULE_SIG_FORCE to care
for signed modules.
And, do I understand correctly, MokManager.efi is signed with the
Microsoft KEK and writes my user key into the UEFI db key store? Thus,
MokManager.efi is a way to get user keys into UEFI db?
> (snip) What actual
> protection does a 'secure boot' bring when compared to, say, an encrypted drive,
> and how complex are each to implement?
I do not disagree with any point you made ;-) Luks and encfs are tools I
use each day.
Oh, I´d also consider to encrypt /tmp and /var.
Secure boot in the first place is a play field for me to learn about it.
But, do not underestimate it. A remote attacker could very well be able
to reboot your machine with his own malicious kernel, if he gains the
necessary rights he does not need to sit in front of your machine. Ok,
before doing that, he has tried many other things before. Inhibiting
loading malicious kernel modules may be much more important and can be
done without secure boot.
And secure boot has one interesting feature, it can store a list of
hashes in its db key store. This way you can ensure certain important
apps have not been tampered with, not only boot loaders. I think this
feature is even more interesting than signing boot loaders.
Imagine, you protect important system apps or files with hashes that are
stored in your system hardware, an attacker will have a hard time to
replace them with malicious code. This feature sound very very
interesting to me.
Am 30.03.2017 um 15:48 schrieb [hidden email]:
> On Wed, Mar 29, 2017 at 09:19:42PM +0200, Malte Gell wrote:
>> And, do I understand correctly, MokManager.efi is signed with the
>> Microsoft KEK and writes my user key into the UEFI db key store? Thus,
>> MokManager.efi is a way to get user keys into UEFI db?
> yes, with MokManager you can enroll your own keys
Oh, is MokManager able to enroll new PK and KEK keys?
That would be awesome, some mainboards have no EFI GUI for doing that
and my Asrock only has a broken test PK..... :-(