Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Comment: Re:Secure Boot + Full disk encryption (Score 1) 324

by vojtech (#49162293) Attached to: Ask Slashdot: How Does One Verify Hard Drive Firmware?

Your example #1 doesn't work. There is no point in the Secure Boot boot process which wouldn't be cryptographically verified. The shims are signed and verified, even the MOKManager is. So the malicious code can run on the drive, but will not affect what is running on the main CPU and the main CPU will not leak any key data to the drive.

For your example #2: I do not care if random bits of my encrypted data remain in a hidden part of the drive. That will happen on SSDs anyway.

Comment: Re:Secure Boot + Full disk encryption (Score 2) 324

by vojtech (#49162265) Attached to: Ask Slashdot: How Does One Verify Hard Drive Firmware?

Of course the UEFI code cannot bypass the drive firmware. From the point of view of secure boot, the boot media is untrusted, and thus it doesn't care whether there is any malicious code in the drive firmware. It simply verifies that anything it loads from there is signed and thus uncompromised. If the bootloader or kernel were tampered with, Secure Boot will refuse to boot.

Comment: Secure Boot + Full disk encryption (Score 4, Insightful) 324

by vojtech (#49158067) Attached to: Ask Slashdot: How Does One Verify Hard Drive Firmware?

Actually, the much hated Secure Boot (with the shim loader, MOK, and GRUB2), combined with full disk encryption (for example using LUKS), and in filesystem compression (btrfs2) can quite nicely protect you from anything that a malicious firmware in a harddrive could do. The firmware will only ever see encrypted data passing through it, except for when loading the bootloader and the kernel, which will both be cryptographically verified by UEFI. The in-filesystem compression is there to compensate for the compression SSD drives normally do themselves to gain additional speed that will be impossible to do that on encrypted data.

Sure, this basically converts the problem to trusting the main BIOS (UEFI), but that's something you have to solve in any case.

Comment: Re:SecureBoot is incomplete (Score 1) 135

by vojtech (#44223237) Attached to: Secure Boot Coming To SuSE Linux Servers

You might want to examine the MOK concept that SUSE has implemented. It allows for custom executables that are checked against a local key.

Regarding configuration, that is outside of the scope of Secure Boot. Its purpose isn't a full system attestation, it's limited to preventing executing untrusted code in kernel space. That alone is of value, as it makes installing persistent and invisible rootkits much much harder. Not impossible, of course - as long as software can have bugs, no security technology can be perfect.

(working for SUSE ...)

Comment: Re:I work at SUSE. (Score 1) 506

by vojtech (#38989731) Attached to: Ask Slashdot: Where Are the Open Source Jobs?

Novell has been acquired by The Attachmate Group (http://attachmategroup.com/) and is now privately owned and the original Novell businesses now form most of what The Attachmate Group is.

TAG is now operating four businesses: Attachmate - their original business, NetIQ - the systems/network/identity/compliance/security-management company, where the Novell Managewise, Zenworks, identity manager, platespin, orchestrator, etc, etc, products are a significant part of the portfolio, then Novell - with the "true" Novell products like NetWare and GroupWise, and finally SUSE, with the Linux products.

And TAG is doing rather well overall.

Regarding the IP, you could've seen in the news that this was abould the old Novell patent warchest. Patents that Novell owned for defense purposes, sort of an atomic stockpile for mutual assured destruction. They've been purchased by a consortium created by Microsoft, Apple, Oracle and EMC and safely stored in an equivalent of a nuclear waste storage facility until their danger to the members of the consortium expires.

And nothing of value to Novell was lost - TAG retained the IP relevant to Novell's, NetIQ's and SUSE's present products. You may argue that with a reduction of the number of warheads TAG is more vulnerable. Novell/SUSE/TAG are still a (contributing) member of the OIN and thus believes it doesn't need to own such a huge stockpile itself.

Comment: Re:Curious... (Score 1) 1017

by vojtech (#35867030) Attached to: Is Sugar Toxic?

However, the more important question (also answered in the article and the video) is:

Why do people eat more than they need? Why, when the human body can detect when it has enough nutrients and signal satiety to the brain?

The answer being: Because we've developed foods (by using high fructose amounts in them, through sugar) that block those signal paths. We've perfected foods that we want to crave and that don't make us feel we've had enough, so that we can consume more.

Yes, one possible answer to the caloric equation is: Have a strong will, be hungry and you'll be lean. The other is: Eat right, and you'll feel satiated after eating exactly the amount that's needed for your health.

And, btw, the equation assumes that all you eat and is digestible gets digested. That obviously isn't true, when overeating a lot of the food just goes through without the nutrients getting extracted. If that wasn't the case, many people would weigh thousands of pounds today.

news: gotcha

Working...