That's essentially correct kevin. The idea was to be able to run not remote, but untrusted code. Note that modern readers will understand that local code can be untrusted. There is a good picture of this in securing java.
gem -----Original Message----- From: Wall, Kevin [mailto:[EMAIL PROTECTED] Sent: Mon May 08 19:17:22 2006 To: Dinis Cruz; Stephen de Vries Cc: Secure Coding Mailing List Subject: RE: [SC-L] By default, the Verifier is disabled on .Net and Java Dinis Cruz writes... > Stephen de Vries wrote: > > Java has implemented this a bit differently, in that the byte code > > verifier and the security manager are independent. So you could for > > example, run an application with an airtight security policy (equiv to > > partial trust), but it could still be vulnerable to type confusion > > attacks if the verifier was not explicitly enabled. To have both > > enabled you'd need to run with: > > java -verify -Djava.security.policy ... > This is a very weird decision by the Java Architects, since what is the > point of creating and enforcing a airtight security policy if you can > jump strait out of it via a Type Confusion attack? > > In fact, I would argue that you can't really say that you have an > 'airtight security' policy if the verifier is not enabled! > > Right? > > Is there a example out there where (by default) java code is > executed in an environment with : > > * the security manager enabled (with a strong security policy) and > * the verifier disabled Just a hunch, but I suspect that it was designed this way to support mobile code, or more specifically applets. There is a security manager enabled (policy not airtight though; see McGraw/Felten's book on the subject) with applets, and the byte code verifier only verifies *remotely* loaded classes, which are the only ones presumed to be hostile. Dumb assumption, I know, but initially applets ran so slow, Sun probably had little choice if they hoped to "sell" applets. Besides, back then most of the hostile code WAS coming from different attack vectors--infected floppies or ftp'ing / running infected code. AV software monitored that attack vector, but not executable code coming in via HTTP through your browser. (Many do today, though.) But the assumption Sun made back then was that all locally loaded classes could be trusted and therefore were type-safe. In retrospect, several wrong decisions were made regarding web security. (Don't even get me started on Radio-ActiveX! ;-) But as they say, backward compatibility is the curse of software design, so we probably are stuck with it. Fortunately the verifier is pretty simple to enable in Java. OTOH, coming up with a good security policy is not so easy. I've only done it twice and it's been a laborious process each time assuming you start with essentially a fail-safe "no permissions" approach and only add permissions as-needed. Anyway, I'd say that applets were probably what drove this security model. Curious that applets probably now comprise less than %1 of all Java code today. -kevin --- Kevin W. Wall Qwest Information Technology, Inc. [EMAIL PROTECTED] Phone: 614.215.4788 <... add your favorite pithy quote about hindsight here ...> This communication is the property of Qwest and may contain confidential or privileged information. Unauthorized use of this communication is strictly prohibited and may be unlawful. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy all copies of the communication and any attachments. _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php ---------------------------------------------------------------------------- This electronic message transmission contains information that may be confidential or privileged. The information contained herein is intended solely for the recipient and use by any other party is not authorized. If you are not the intended recipient (or otherwise authorized to receive this message by the intended recipient), any disclosure, copying, distribution or use of the contents of the information is prohibited. If you have received this electronic message transmission in error, please contact the sender by reply email and delete all copies of this message. Cigital, Inc. accepts no responsibility for any loss or damage resulting directly or indirectly from the use of this email or its contents. Thank You. ---------------------------------------------------------------------------- _______________________________________________ Secure Coding mailing list (SC-L) SC-L@securecoding.org List information, subscriptions, etc - http://krvw.com/mailman/listinfo/sc-l List charter available at - http://www.securecoding.org/list/charter.php
