(A)bort, (R)etry, (I)gnore: Perspectives on Information Security

To the tune of U2′s “God Part II”:

I don’t believe in the ACM
I don’t believe in the IEEE
I — I’m going to set my mind free

I don’t believe in publication counts
Don’t beli’ve in acceptance rates
I — I’m going to ignore PC gates

I don’t want to bloat my CV
Don’t want to have a Dean to please
There are outcomes other than these

Rewrite without GOTO’s:

http://lxr.linux.no/linux+v3.1.3/mm/mmap.c#L1181

Go ahead, I’ll wait.

Debugging the OS, even with full source, full debugging symbols, and a framework like kprobes or DTrace is a very hard exercise.

Debugging OS X from a user perspective (without access to source, and with skimpy information in a crash report) is almost impossible.

I’m willing to speculate a bit, though.

My recent kernel panics are likely the result of two possible conditions: (1) an actual race condition bug in the kernel; or (2) interference with the kernel data structures that manage locking by some 3rd-party software loaded into the OS as a module. On my system, the only “foreign” code loaded into the OS are drivers for my Microsoft Mouse and Keyboard (let’s face it, Apple keyboard suck, and the one-button-trackpad-click-multi-touch interface is just a nightmare as a pointing device) and VMware:

loaded kexts:
com.microsoft.driver.MicrosoftMouseUSB 6.2.2
com.microsoft.driver.MicrosoftMouse 6.2.2
com.microsoft.driver.MicrosoftKeyboardUSB 6.2.2
com.microsoft.driver.MicrosoftKeyboard 6.2.2
com.vmware.kext.vmnet 2.0.4
com.vmware.kext.vmioplug 2.0.4
com.vmware.kext.vmci 2.0.4
com.vmware.kext.vmx86 2.0.4

I’m willing to believe VMware may be the culprit here, particularly since I’ve started using it heavily since Migrating to the new notebook. My copy of VMware Fusion is a few revisions behind (I think), and OS X is up to date. I didn’t have problems with it on my previous Macbook Pro (although I did have other problems with that notebook). I’ll try updating VMware Fusion and see if that resolves the problem (although it is naturally tough to test the absence of something).

PKI is typically the object of much scorn: something this inherently dependent on human-level trust surely cannot provide digital trust, especially between (for example) countries that have no diplomatic ties. See, for example, the classic point/counterpoint:

Ten Risks of PKI: What You’re Not Being Told

7 and a Half Non-risks of PKI

For these kinds of reasons and what has become a certain amount of institutional prejudice in the security community, PKI typically takes more constrained forms: SSH host and user keys; SSL server certificates signed by a slew of vendors pre-installed in major browsers, etc.

The experience of Dartmouth and its partners in academia and government provides a model for extending PKI into the real world across organizational boundaries.

This Canadian scifi writer doesn’t seem to understand the concept of DoS, or the abuse potential of a deeply embedded surveillance and monitoring system. He claims that we could have

a small implant, say, that keeps track of your whereabouts using signals from the satellite-based Global Positioning System. Suppose the implant constantly broadcasts your exact location to a centralized facility. At that facility — call it the Alibi Archives — you would have your own personal black box, keeping track of your movements.

He claims that such a device would reduce crime and more quickly bring help for medical emergencies. He utterly neglects the ease with which such a small transmitter could be interfered with, and he does not seem to realize that creating a domestic surveillance system actually introduces the temptation to become totalitarian. The Protect America Act and the PATRIOT Act have had their original provisions expanded to deal with ordinary crime, not just terrorism. Government is by definition a bureaucracy. Its natural tendency is to grow, increase its scope, and subsume things that don’t rightly belong to it.

Is more public monitoring of private lives a good thing? He also doesn’t seem to realize that data, once stored, is a devil to get rid of — he is rather idealistic in assuming that law enforcement, the government, and your employer won’t try to find out what you have stored in that black box. Are you a political candidate running for office? Let me file a freedom of information act and see what you really said at that frat party 20 years ago.

I have been thinking of a new way to express an old idea about the need to trust and verify various components of a system. Inspired by the W^X (write XOR execute, a way to prevent the execution of injected code) relation, I think I came up with a good trust pattern. The pattern is:

Trust XOR Verify. Trust or Verify, but not both, and not neither.

In security systems, it is often desirable to verify the properties of code that are relevant to its trustworthiness. In essence, users of a system traditionally face a choice: either trust the code that you execute (thus tacitly admitting that it can violate your security) or verify the security properties of the code so that you have some assurance that the code behaves as expected.

If you verify the properties that you trust, doing so introduces needless overhead. If you don’t trust a component, but you don’t verify it, then you are exposed to needless risk. So, you should either trust a component but not verify it or not trust a component and so verify it. This logic is captured exactly by the XOR relation:

Trust   Verify    Trust XOR Verify
 T         T                 F    (needless performance degradation)
 T         F                 T    (acceptable risk, no performance degradation)
 F         T                 T    (non-acceptable risk, justified degradation)
 F         F                 F    (needless risk)

Great article, linked from Slashdot:

A Mathematician’s Lament by Paul Lockhart

Many of the same observations hold for Computer Science and hacking.

Smart Energy Grids will save us, the planet, and possibly the universe. We should rest assured that the industry, with the help of smart academics, knows what it is doing:

http://us.cnn.com/2009/TECH/03/20/smartgrid.vulnerability/index.html

Also, industry representatives said, they have no intention of putting an unsafe grid online.

"We are not going to manufacture this car without a seat belt," said Ed Legge, a spokesman for the Edison Electric Institute."


That sounds comforting. But seatbelts don’t do much against side-impact crashes, or alien laser rays, now do they?

[The original email spurred a piece of funny commentary by Sergey about "security by analogy" -Ed.]