[opensuse-security] signing custom kernel for secure boot
Hi there, 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 module!? 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? regards -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
On 29/03/17 07:04 AM, Malte Gell wrote:
[...]
But, I am a bit confused, this guides signs vmlinuz, but not a single module!? 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. -- Machiavelli -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
Am 29.03.2017 um 14:46 schrieb Anton Aylward:
(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. regards Malte -- To unsubscribe, e-mail: opensuse-security+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-security+owner@opensuse.org
participants (2)
-
Anton Aylward -
Malte Gell