>previously, Russ said...
>>To me, the inherent insecurity of Java is that it is supposed to be viewed
>>as secure.
>
>and Ray replied...
>"I disagree. Java is only as secure as its architecture / design /
>implementation /environment permit."
>
> Sorry Ray, but I find these kinds of statements pretty condescending. It
>applies to everything everywhere. Of course, any *thing* is only going to be
>as secure as its architecture/design/implementation/environment permit, so
>what's your point. The Java applet is meant to run inside a reference VM that
>is supposed to be secure. If it isn't secure, its not by design, its by
>fault. Where that fault lies is irrelevant, JavaSoft say that the VM should
>be trusted to the extent that, if properly implemented, it cannot be broken
>out of. They say that I can trust a Java applet not to be malicious, but so
>far, the implementations of the VM have not been able to live up to that
>expectation. JavaSoft still says that they will be able to assure us of the
>VM, eventually. Netscape keeps putting out versions that say they have fixed
>the VM to prevent malicious applet problems.
>
> ActiveX, on the other hand, doesn't claim any responsibility whatsoever for
>what an object can or cannot do. They do not try to give you a sandbox, you
>have to make that yourself.
>
> The inherent integrity check is part of what proving ownership is all about.
>They are able to prove that the object has not been tampered with, which is
>what I assume you are referring to when you say "inherent integrity check".
>They cannot prove that the object will not be malicious, or that it will not
>contain a virus, only that it is the same as the one they put the signature
>on in the first place. If the original object had a virus in it when it was
>signed, then you will get infected with a virus, period. What I'd like to see
>are additional signatures from third parties telling me that the object has
>been checked and deemed not malicious, or secure, or virus free, or
>whatever...something more than just "its from Microsoft so trust it". So yes,
>the signature is made from a hash of the object.
>
>Ray said...
>"Ahhh, another hot topic. Seems to me that this is an implementation
>question that everyone faces. Dealing with certificate revocation is a
>handfull. Seems to me that checking with the CA each time is an
>implementation option in most schemems? Can anyone comment?"
>
> Its not an option in IE 3.0b2, nor is it intended (at this point) to be an
>option in any MS implementation of the API (according to their evangelists).
>
>Ray said...
>"As I believe is always the case unless: 1) The CA always checks it's
>revocation list or maintains an active list of ALL certiciates - and / or -
>2) The client always asks the CA to do so. True?"
>
> If #2 doesn't happen, #1 is only useful for clients that have never accessed
>the object before.
>
>Ray said...
>"From my read of implementor's concerns with making increased security
>available, the performance hit of such things as having the client ask the CA
>to check upon every access - although I'll bone up on ActiveX and figure this
>out."
>
> I have many ideas of how to solve this problem, but I am trying to make them
>into a commercial product. Performance doesn't have to be an issue at all.
>
>previously, Russ said...
>>This doesn't represent a problem for the sale of software, but it obviously
>>represents a problem if ActiveX objects are used the way Java applets are
>>used.
>
>and Ray replied...
>Not necessarily, me thinks. Looking at the Java 1.1 Security API (shipping
>late Summer or early Fall) it looks like these are all implementation
>choices.
>
> Well, the Security API is not released on JavaSoft's web page, so any idea
>where I can get a copy? By the way, we are talking apples and oranges here.
>My issues with Java have to do with the Virtual Machine, not the Java
>language. The VM imposes restrictions on what language components you can use
>in an applet. I suspect that the Security API may allow better
>implementations of the VM to be created, but who knows when or how well.
>Today, in the VM, we simply get a SecurityException thrown, which some VMs
>ignore, or alert yet proceed. A list of constraints the VM imposes on applets
>can be seen at;
>
> http://java.sun.com/books/Series/Tutorial/applet/security/security.html
>
>previously, Russ said...
>>I agree that securing the VM should be possible, but so far, its been
>>impossible to guarantee. Sun and Netscape may be very security conscious,
>>but the simple reality is "can we ever completely trust them?".
>
>and Ray replied...
>"No, and they say so - explicitly. All they say: if you follow these rules,
>you'll have X level of security (modulo the bugs, implementation errors, and
>brain fade in application of the technology to the problem at hand,
>deployment, operations, and management, of course.) Just like the sane
>firewall vendors and any other sane security product vendors.
>
> To quote from the VM Security Restrictions page from JavaSoft's web site;
>"One of the main goals of the Java environment is to make browser users feel
>secure running any applet. To achieve this goal, we've started out
>conservatively, restricting capabilities perhaps more than necessary. As time
>passes, applets will probably get more and more abilities. "
>
> This sounds diametrically opposed to your statement of what Sun has
>supposedly said.
>
>Ray said...
>"I disagree. If you want to be secure, you can be. Its all in the defintion
>of what this means to each organization and wheather they will pay the price
>to meet their goals."
>
> Come on Ray, the Security API is not yet published, let alone implemented on
>a reference platform, let alone included in a commercial product, so what do
>you mean you can be secure? You could pay the price to have someone program
>you a way to screen applets, and you could also pay the price to implement
>full desktop security covering everything from soup-to-nuts. Bottom line is
>that if you want to feel totally secure with Java applets (or ActiveX
>objects) today, you have to screen them out, period. Give me one example of a
>completely secure, commercially available, browser available today that will
>run Java applets, or even a combination of browser and some kind of screening
>server that will give me complete security. The price is irrelevant, if my
>goal is to be able to trust Java applets, as Sun says I should be able to, I
>cannot meet it today.
>
>Ray said...
>"I disagree. It will be as scure as you make it. If there are ActiveX
>defficiencies, those who want to use it will have to ensure that those
>defficiencies do not defeat their security goals - just like firewalls and
>any other security product."
>
> You must be talking about a completely in-house environment here, otherwise
>how can I ever *ensure* that a third-party object does not contain
>deficiencies that compromise my security goals, with technology available
>today? Even with future technology, unless both Java applets and ActiveX
>objects include far more identifiable information in them (bit patterns, or
>whatever else it takes for something to determine what an object is going to
>do before it executes), then how will I be able to enforce my security goals?
>
>Ray said...
>"The OS's protection mechanisms must allow implementers to protect the comm
>protocols stack, applications.... - as they choose - past the basic design
>requirements of the OS's protection mechanisms. That is, in some cases, the
>basic design requirements of the OS's protection mechanisms *preclude*
>everything except a very, very narrow set of comm protocol stack,
>application... functions. In other cases, the basic design requirements of
>the OS's protection mechanisms *allow* everything. The balance point is
>found in building an OS that offers a variety of protection mechanisms.
>Unless I'm on a diferent planet here, these are calledSingle Level (security)
>Systems and Multi Level (security) Systems, respectively."
>
> Next to the former Vice-President of Liberia's request for a room to bonk
>his girlfriend in, that has to be the most confusing paragraph I have ever
>read. I'm sure you had a point there, but for the life of me I have no idea
>what it was.
>
>previously, Russ said...
>>Something developed for Netscape stays in their Browser (until they release
>>a complete OS that is), and so the scope of the product is somewhat more
>>limited (IMO). Products like Nortel's eNTrust can be extended to have the
>>ability to do far more than just handle objects arriving via the browser.
>
>and Ray replied...
>"Ummm - IMHO, both (and all others) rely on the afore-mentioned property: the
>OS must support and protect the security mechanisms that use them - they can
>not stand on their own. Sorta like a house of cards in my view."
>
> Ummm, isn't this just like the VM that Sun says will protect you from rogue
>applets? Of course, and once again you state the obvious here, any security
>mechanism that is put on or into an OS is going to have to integrate itself
>with the OS sufficiently to secure it, and anything else its intended to
>secure. The success or failure of a security mechanism will depend greatly on
>the original design of the OS, and how the OS allows security mechanisms to
>interface with it. However, so far no implementation of a completely secure
>OS has been anything other than user hostile (IMO), so its not yet
>commercially viable to do complete security on a widespread basis.
>
>previously, Russ said...
>>The Java language, on the other hand, is a very different animal than Java
>>applets.
>
>and Ray replied...
>"Yes - language vs program, true?"
>
> No - program vs. applet that runs in a VM! Both use the Java language, but
>they are very different animals.
>
>Ray said...
>"IMHO they can't be seperated. If the language does not support security
>features, programs written in them - more of less by definition - can not be
>secure."
>
> As virus in DOS have proven over and over again, if I intercept acceptable
>calls and redirect them somewhere else, I can change the basic functionality
>of the environment. So if I intercept all calls to a disk drive and respond
>properly with malicious information, the OS does not know the difference. In
>the case of applets, the VM prevents normally acceptable Java language
>functionality. In this case, its the security and integrity of the VM, not
>the language. I agree, however, that in writing the VM the security features
>of the language are incredibly important, as is the security features of the
>underlying OS, although Sun believes they can make a secure VM on most OS'.
>
>Ray said...
>"Agreed. Further, I assert that this can not be done w/o an OS that can
>properly protect those security mechanisms."
>
> You're article has seemed to have shifted focus from Java to operating
>systems. Java is intended as an open language capable of being implemented on
>any OS, don't forget that.
>
>Cheers,
>Russ
>...eek, quick, someone give me some broken software, I'm suffering beta
>withdrawals...
|
|
