winscape 2312
That, Barb, is an interesting observation. A finer distinction than your usual compiler v OS thinking. Dave Cutler, as far as I know was the first with $INTSAV, $DIRXT and...
snip
snip Maybe what we have here is another translation problem? involving "user mode"? My understanding of...
But code loaded as a user mode program .... Doesn't that limit the amount of damage the code can do? which would seem to be a good thing, for code that might or might not be trustworthy.
Oh. Yipes. That "retrieves it from the Internet" .... This sounds like another case of happily turning over control to code from a source that might not be trustworthy.
snip
Sure. But:
Not all operating systems enforce the "only to yourself" rule, no? A single-user "operating system" that doesn't make a distinction between regular user(s) and an administrator ....
And even if you can only damage your own files, well, that's not good either.
How so (about backdoors)? My claim is that if you make it easy (and even automatic) to run executable content from sources that might not be trustworthy, you have a potential problem. I'm interpreting "executable content" broadly here -- standalone programs, Javascript maybe, Word files with macros, etc., etc.
Thought you'd like that way of putting it.
People writing mulbreasthreaded applications, though, do have to deal with bugs that can't necessarily be reproduced at will. "Compiler thinkers" or .... what was the other side? "o-s thinkers"?
But possibly only people writing operating systems have to deal with bugs that depend on, hm, how to say this -- real-time interaction between hardware and code?
snip
Ah. Got it.
Well, the original security model for Java strictly limited what applets could do -- no reading or writing of local files, no network communication with any site other than the one from which they were loaded. The idea was that you could then turn over control to an applet from any source, even one that might not be trustworthy, without significant risk.
This is a device driver not an application. That depends on the architecture of the OS. Most device drivers have to be intimate with the kernal in some fashion. I don't know about...
Of course, it also makes it tough to do many kinds of things you might *want* an applet to do. So there have been various changes to this original model, which I haven't kept up with, but I believe there's some notion of "certificates" that identify supposedly trustworthy applets and allow them more access to the system -- as would be needed for the kinds of applications you're talking about below (banking, e.g.).
I don't know how bulletproof any of this is (probably "not 100%", though the design of the original Java security model gives me some degree of hope that the people at Sun are not clueless about security issues).
-- B. L. Mbuttingill ObDisclaimer: I don't speak for my employers; they return the favor.