>On Tue, 30 Jul 1996, Ray Kaplan wrote:
>
>> > Java Security? What security? You either trust the VM or you don't,
>
>Java is bad,
Java certainly seem to be lacking. I am, however, exploring the
architecture with folks of various kinds (Sun, Netscape...) and, I seem to
be coming to the conclusion that Java (obstensibly) relies on its "wrapper"
(e.g., a browser) to support its inate security features. Headed in the
right direction here?
>methinks active X may be worse.?
Perhaps, but I'd suggest that this is only because it is younger and built
on much less mature platforms than where Java comes from? Heaven only knows
what we'll find with ActiveX and the others that come along, eh?
>> Indeed, however, considering that there is currently no authentication,
>> this is almost a no op. Discounting bugs in the particular client VM,
>> there is an open question: can you trust the applet itself. Nope, not
>> by definition. Hop on over to one of the many "malicious" applet
>> providing sites and see how well your netscape gets hammered (via Java
>> and HTML) for a demonstration of this. In my perfect world (which seems
>> to be where Sun and other are going), you'd sign your applet and it's
>> end user would make the decision to trust you (or not, as it were.)
>
>I for one, don't find this to be a "perfect world".
Amen. Less so every day as a matter of fact ;)
>It's bad enough
>getting my users to understand how to select a secure password, and
>that you shouldn't write it on a sticky note pasted to the monitor. Now
>I'm supposed to explain to them the variances of extending trust?
Ahhh - and there-in lies the rub. I've found the Java and Netscape people
to be very security concious and very concerned about all of this. It is
becoming interesting for me to continually note how many of the basics
simply keep coming up - again, and again, and again. (I'm threatening to
team up with a few other security consultants to write a "war stories"
collection to emphasize the fact that most (if not all) of what we seem to
do is re-treat the same basics in different settings. Its sorta like:
moving a strange-minded sports team around the world. At each new venue,
this team expects to start from scratch and invent their own rules.
Meanwhile, the oficials go crazy trying (over, and over, and over...) to
explain that the rules of the game don't change just because you change
venues. Interestingly, I find the Sun and Netscape people to be quite well
anchored in security basics and saying the same things that you are (e.g.,
passwords, trust...) However, in the end, its us user-side (users,
admins...) folk who are dropping the ball. My contention is that security
(or lack there of, is always a management issue (franchise, budget... for
those who actually do it.) I'm starting to feel better again.
>> I've a model for "applet brokering" which includes the usual digital
>> signatures for authentication / integrity, AND some other stuff that is
>> pretty ugly. Consider that you'll need *someone* to guarentee that the
>> applet is safe *and* someone to ensure that the client won't allow abuse.
>> A pretty big mess, me thinks. Although, maybe we'll see a few more
>> millionaires as companies are formed to tackle these tough jobs ;)
>>
>
>Methinks "applet scanners" could become a buzzword.
Indeed. Turns out that the Finjan scanner seems limited in its V1 release,
BUT - it is still doing things that would otherwise take some doing by
admins who wanted to watch their applets run and observe their
security-realted behavior. In all, I keep thinking we are living in a
strange world where vendors are jumping in to correct the ills of the
basic OS and network security-realted defficiencies that exist. That is,
in light of today's OS / network / application / firewall defficiencies,
looks like vendors like Finjan will be the ones to fill the void - until we
get our collective acts together.
>
>> > Problem with malicious applets is, assuming
>> > they are able to break out of the VM, that they can attack the hosts
>> > you thought were secure, because they run from inside your Firewall.
>
>Which menas they shouldn't be able to break out of the VM. Not a simple
>task, but certainly not unattainable.
Indeed, but given that the VM depends on the OS / network stack for its
support, consider that the VM may not be the problem.
>> Yep, but consider that this implies an interesting and very onerous
>> (impossible?) responsibility for every PC on the net? Whoooa. Sounds
>
>Worse, with signed applets and the like, it starts to place the
>implementation of security policy on the end-user. This is Not a Good
>Thing [tm].
Amen - unless, they own and control the box where it runs *and* know the risks?
>> of a chosen security policy. And, finally, the really tough nut - it would
>> be great if the policy could be mapped seamlessly into that of the security
>> domain which provided the applet (for purposes of access control and
>> authorization...) IMHO, very few firewalls even can do that stuff today.
>
>This is starting to become essential.
Yep. Now, how to do it without the nightmares of implementing DCE / SESAME...
RayK
|
|
