Tuesday, September 2, 2008

Do you want me to bother you?
YES
NO
NEVER

One of my problems with geeks is they often don't understand the inverse of signal to noise. Someone talked about the E programming language today, and I read the "walnut."

My god, what a nightmare. I'm not a technical person, but the more I read, the more I realized how broken by design this language is. Let me quote the block that made me wonder who was drinking what when they concocted this misbegotten mess:


Let us look at an example in a computing context, of how keys/capabilities would change security.

Consider the Melissa virus, now ancient but still remembered in the form of each new generation of viruses that use the same strategy the Melissa used. Melissa comes to you as an email message attachment. When you open it, it reads your address book, then sends itself - using your email system, your email address, and your good reputation - to the people listed therein. You only had to make one easy-to-make mistake to cause this sequence: you had to run the executable file found as an attachment, sent (apparently) by someone you knew well and trusted fully.

Suppose your mail system was written in a capability-secure programming language. Suppose it responded to a double-click on an attachment by trying to run the attachment as an emaker. The attachment would have to request a capability for each special power it needed. So Melissa, upon starting up, would first find itself required to ask you, "Can I read your address book?" Since you received the message from a trusted friend, perhaps you would say yes - neither Melissa nor anything else can hurt you just by reading the file. But this would be an unusual request from an email message, and should reasonably set you on guard.

Next, Melissa would have to ask you, "Can I have a direct connection to the Internet?" At this point only the most naive user would fail to realize that this email message, no matter how strong the claim that it came from a friend, is up to no good purpose. You would say "No!"

And that would be the end of Melissa, all the recent similar viruses, and all the future similar viruses yet to come. No fuss, no muss. They would never rate a mention in the news. Further discussion of locally running untrusted code as in this example can be found later under Mobile Code.

Before we get to mobile code, we first discuss securing applications in a distributed context, i.e., protecting your distributed software system from both total strangers and from questionable participants even though different parts of your program run on different machines flung widely across the Internet (or across your Intranet, as the case may be). This is the immediate topic.


This is patently idiotic, and is the product of an egomaniac's delusional ravings. I've used Vista, which asks every two steps to do this that or the other. I won't use it again. Why? Because having a user guard ever single capability for ever single time means dozens of confirmations. What do people do? They turn them off after the first few times. If this is what capabilities does, then caps are useless. Instead what we want is a situation where safe use cases are recognized, and only strange ones are not. This would mean say, something smart enough to grab the whole list of capabilities required, and present us with a dialog box that gives us some idea of what is going to happen.

Absent that, it is nagware.

But there's more:


Keys

In the real physical world, if you had to depend on children to fetch CDs, you would not use an ID badge. Instead you would use keys. You would give the child a key to the front door, and a key to the CD cabinet. You would not give the child a key to the gun vault.

All current popular operating systems that have any security at all use the ID badge system of security. NT, Linux, and Unix share this fundamental security flaw. None come anywhere close to enabling POLA. The programming languages we use are just as bad or worse. Java at least has a security model, but it too is based on the ID badge system--an ID badge system so difficult to understand that in practice no one uses anything except the default settings (sandbox-default with mostly-no-authority, or executing-app with total-authority).

The "children" are the applications we run. In blissful unawareness, we give our ID badges to the programs automatically when we start them. The CD cabinet is the data a particular application should work on. The gun vault is the sensitive data to which that particular application should absolutely not have access. The children that always run to get a gun are computer viruses like the Love Bug.

In computerese, ID badge readers are called "access control lists". Keys are called "capabilities". The basic idea of capability security is to bring the revolutionary concept of an ordinary door key to computing.


I'm no security expert, but if an area is really supposed to be secure, then it has ID badges, not keys. The problem with keys is that they don't know who uses them. What we really want is a key with an access control list and a time on it, like, for example, a credit card number that is one use.

Marc Stiegler likes to be very judgemental about others, so I will apply the same standard to him. He's a arrogant moron who produced a monument to his ego, which is a complete disaster area. He wrote this in 2000, and there is a reason why "E" isn't sweeping the planet. Because it is the creation of a narrow mind who makes huge claims and then delivers something which self-evidently won't work.

3 comments:

  1. I'll admit, user account control was one of the first thing I turned off the moment I figured out how.

    Then, after I got tired of my computer treating me like a freaking moron all the time, I switched to linux. :P

    ReplyDelete
  2. Do you want KEYBOARD to have the ability to input the letter "D" ?

    YES NO

    Do you want mouse to have the ability to move pointer?

    YES NO

    Do you want mouse to have ability to input left click?

    YES NO


    I also don't see why we needed a new programming language, especially since this one runs on top of another, when what was important was the promise and data stuff.

    Which is, in the words of my security minded partner, "Brain damaged." I asked why and he said we'd be getting to that case shortly.

    (Great beret, really works with that hair.)

    ReplyDelete
  3. Seriously! Add to that the fact that Vista hides all its settings behind multiple boxes... even display settings, which used to be in one convenient to use tabbed window, is now separated out into multiple boxes, as if they figured the average computer user was too stupid to figure out TABS.

    It's the same way throughout the OS... I used to be able to find the network devices with a single entry in the start menu. Now, they have conveniently hidden it behind another box, which, as far as I can tell, adds no real functionality whatsoever.

    "Brain damaged" doesn't begin to describe this...

    ((Thanks!! It's Decalloge's "Oh So French Beret" I found it on OnRez for only 10L, if I remember correctly...))

    ReplyDelete