Please create an account to participate in the Slashdot moderation system

 



Forgot your password?
typodupeerror

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

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 324

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 324

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 135

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 506

+1 Funny. Anyway, SUSE has grown much beyond Nürnberg, even though the HQ has been moved back to Nürnberg recently. I personally am located in Prague, but we have employees on all continents with the exception of Africa and Antarctica and I'm not sure how long even that exception will hold. ;)

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

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 Reheater system. (Score 1) 209 209

No. The reheater system uses the waste heat from the AC to reheat the air back to reasonable indoor temperatures. There is no extra energy needed for heating, in fact less energy will be consumed if the output temperature is higher: The AC condenser will get better cooling and the efficiency will increase.

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

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.

If you think nobody cares if you're alive, try missing a couple of car payments. -- Earl Wilson

Working...