[71] in java-interest
Re: definition of security and safe?
daemon@ATHENA.MIT.EDU (Chuck McManis)
Tue May 9 14:22:32 1995
Date: Tue, 9 May 1995 00:25:24 -0700
From: cmcmanis@scndprsn.Eng.Sun.COM (Chuck McManis)
To: java-interest@java.Eng.Sun.COM
> Thanks for the very detailed answer. So the other way to look at
> my original e-mail would be ``What is "damage"?''. I would look
> at all of these as "damage".
Well in security conferences there is a pretty crisp definition
of "vulnerabilities" which equate to the potential for something
"undesireable" to happen. There is some subjective measurements
applied to how undesirable something is, ie getting root access
is REALLY bad, forcing the user to send a kill -9 to the HotJava
process is just bad.
For each vulnerability, it has to be analyzed for how "bad" it is,
versus how much it costs (in terms of system complexity, etc)
to protect against it, versus whether or not it enables other
bad things to happen etc.
Using your list:
>> 1. granting root access to my machine to another machine on the internet
Very very bad, should never be allowed to happen.
>> 2. reformatting a disk
Again very very bad, should never be allowed to happen. (On UNIX preventing #1
gets you #2, on Windows NT that isn't true)
>> 3. rebooting a machine
Very bad, should not ever happen. However if it does happen it isn't quite
as fatal as 1 or 2.
>> 4. allowing Java code the same permissions as the user of Hotjava
This is bad if it enables other vulnerabilities (like disclosure of
private information.) In itself it isn't "bad" per se. Also the notion
of permissions is unix centric but the point is well taken.
>> 5. displaying rude pictures to unsuspecting users
>> 6. ditto for sound files
These come under bad, but entirely too expensive to prevent. True
prevention would require a way of recognizing an image or sound as
"rude" which even humans can't agree on, much less computer programs.
>> 7. allowing Java code to hog system resources (CPU time, swap space,
>> memory, etc.) without control
In my mind this is worse than #'s 5, 6 because if it allows the
system to be distracted it can enable other things to occur. I am
hoping to get it fixed such that "untrusted" threads cannot set their
priority above a certain limit (which is lower than the user interfaces'
priority.)
>> 8. allowing Java code to exit Hotjava if I don't want it exited
This is bad and can be fixed by making sure the implementation of System
checks for this condition. In particular many of the system methods fall
under this category and we'll review all of them before release.
>> It sounds like Java draws the line between 4 and 5.
Given my sort of off the cuff analysis of your vulnerability list I'd
say that only 5 and 6 would be "allowed" and this only because I can't
think of any way to recognize the contents of a photo apriori.
Now given that, we also want to make sure there are mechanisms in place
to allow sophisticated users to enable access to things from classes they
really trust. Some very interesting applications can be built in Java
and some of them would need your complete confidence.
>> BTW, I think the definition of safe used by Java is the same as
>> that used by the other "safe" web languages out there. So I don't
>> mean to pick on Java. In fact I like Java, it is really cool.
That's quite all right, and yes it is the same. Java adds a notion
of security and trust but you are correct in your observation.
One of the mental stumbling blocks is to differentiate security
as it relates to Java the language, versus security as it relates
to HotJava the web browser. My focus at the moment is to make sure
that the language is safe and secure as I see that as necessary
(but not sufficient) to enable safe and secure applications (such
as HotJava).
--Chuck
-
Note to Sun employees: this is an EXTERNAL mailing list!
Info: send 'help' to java-interest-request@java.sun.com
