While here at Java Jolt we've only touched on security tangentially, and only a few times at that, it's been a major preoccupation with Java users and spectators around the world. For good reason, certainly: a Java applet is a far cry from an HTML tag. Security
Unlike the good old days when the average computer user ran only shrinkwrapped commercial software, and perhaps a few programs written at home, the opening up of our computers to the networks of the world, followed by the creation of programs that allow the effortless execution of anybody's random program (that is, modern Web browsers), have created an environment where the voice of any person, even the most sociopathic, may be heard by your CPU. Trust is suddenly an issue.
As we said last week, security is as much a philosophical issue as a practical one. It goes beyond simply attempting to prevent an applet from reading from or writing to your computer's hard disk. Real security encompasses a more general "assurance" that goes far beyond simple access control. This assurance is as elusive as artificial intelligence.
To illustrate with an anecdote, during my first experience with UNIX, I remember being sat down in front of an older Sun workstation, and watching the local UNIX guru make my user account. He explained as he worked what I partially knew already: that UNIX, unlike any PC operating system I knew at the time, implemented access control for all its files and memory. There was no way that an "unprivileged" user (theoretically) could modify the part of the disk that wasn't his (or hers), and no way his (or her) programs could read from or write to RAM memory that wasn't his (or hers), and so forth--bugs and minor flaws with this system notwithstanding, of course. Then, once my account was created and handed over to me, I heard this striking phrase:
"Go ahead and do anything you want. You can't break anything."I remember thinking that was a very strange thing to say. Even then. It was not long after that when I came across one of the more notorious attacks in the history of Unix security, known affectionately in our high school as "The Login Spoof." It's a simple program that anyone with a little experience can write; it just asks for a username and password, the same way the computer's login program does. It records what people type in, usually gives a message like
"LOGIN INCORRECT", and, often enough, logs out to let the real login program field the next attempt, leaving the unsuspecting user none the wiser. When left running on a blank screen, it invariably attracts people to give up their passwords. Thus, all Unix's access control measures can be completely circumvented, without actually having to violate them.Or, as part of the Java Security Faq glibly admits, "It is hard to automatically tell the difference between an MPEG decompressor and a hostile applet!" You can tell, of course, that the Java authors had heard of login spoofing. They attempted to make sure that it would be hard for an applet to imitate another program on your screen by tagging every window created by an applet with some warning marker. But this is a solution for a symptom, not a problem.
>From a practical standpoint, the Java approach to security was about as good as could be expected. In other words, it's full of holes, as evinced by the faq we just mentioned, but it's programmatic underpinnings appear to be largely sound. You could say, theoretically, that Sun will eventually fix all the holes in the class loader, the verifier, the type system, and so forth, and Java would be completely secure--at least, from frontal attack.
The Java Virtual Machine could theoretically, at some point in the future, completely shield a Java applet from the rest of your computer. This seemingly simple task is surprisingly complex, and the JVM takes a number of steps to accomplish it. At a low level, it enforces data types, creates and preserves separate (and confined) memory for your program, and more generally acts as an arbiter between bytecodes and your CPU. Attempts, through bytecode, to operate outside of an applet's normal realm of influence are simply not allowed to execute. A delicate and careful balance is hopefully maintained between efficiently translating bytecodes directly into real machine code and carefully screening every instruction to make sure it operates within well-defined boundaries. At a higher level, the SecurityManager comes into play.
According to the section of the Java Tutorial on applet security restrictions, "When a SecurityManager detects a [security] violation, it creates and throws a SecurityException object." This wording leads most people to a mental picture that is completely contrary to how this actually works. In actuality, most of the important routines in the Java API are designed to call a corresponding routine in the SecurityManager, if one exists, which will either throw an exception or just return harmlessly, depending on what the running SecurityManager is programmed to do. The SecurityManager is, thus, not watching anything. It's just serving as a placeholder for what the current runtime environment wants to allow, and depends entirely on the API to ask its opinion in the first place.
This is actually not a bad or even unusual approach to this problem. It's just a simple system for allowing customizable levels of trust for various applets, the heart of which exists within the API and not the manager itself. It works perfectly as long as, at the low level, applets can't modify, for instance, the API code or the SecurityManager.
As we've already pointed out, this is rather academic. In fact, we've only ever-so-barely scratched the surface of this issue. Over the coming months, our desire to share not only information, but programs, over the Net in an effortless (and/or "automatic") fashion will undoubtedly bring our definition of trust, with respect to our computer, into sharper focus. For our part, next week, we'll delve just a little deeper into the tangle of security.
