Dinis,
Dinis Cruz wrote...
Finally, you might have noticed that whenever I talked
about 'managed code', I mentioned 'managed and verifiable code',
the reason for this distinction, is that I discovered recently
that .Net code executed under Full Trust can not be (or should
not be) called 'managed code', since the .Net Framework will
not verify that code (because it is executed under Full Trust).
This means that I can write MSIL code which breaks type safety
and execute it without errors in a Full Trust .Net environment.
Indeed this is somewhat surprising that there is no byte-code
verification
in place, especially for strong typing, since when you think about it,
this is not too different than the "unmanaged" code case.
Apparently the whole "managed" versus "unmanaged" code only has to do
with whether or not garbage collection is attempted. Given the fact
that Microsoft has added almost 50 new keywords just for their new
"managed C++", one certainly could hope they could do better than
this--IF this applies to ALL "managed" code in general.
However, the real question is "is this true for ALL managed code or
only managed code in the .NET Framework"? If it is the latter, I don't
see it as being much different where Java java.* packages may use
"native"
code (via JNI) in (say) rt.jar to interface with OS-level constructs.
I believe that such code is fully-trusted in the JVM as well. Of course,
it is reasonable to ask of Sun Microsystems and Microsoft to restrict
such trust
for "native" and "managed" code (respectively) by requiring it be
limited
to digitally signed jars / assemblies signed by trusted sources that are
verified at runtime when these jars / assemblies are first loaded. This
could
be extended so that the "trusted sources" ultimately could be defined
by the end users (or their administrators), but by default, it would
include
the vendors (Sun and Microsoft) themselves. I recall early versions of
Sun's
domestic JCE jars that were distributed as separate jars. The
verification
of the signatures for these signed jars significantly slowed down the
initial
loading of those jars, but after verification, it had little, if any
performance impact. Of course if software quality improvement does not
take
place in these companies, their signing would be somewhat vacuous. But
it
would be better than nothing, since at least all such code would not be
fully trusted by default.
Of course (not to open another can of worms) if we could actually
enforce
liability for software just as we commonly do with other manufactured
products, we problably wouldn't need some elaborate constructs to ensure
secure coding. Because once some of the major vendors had had their feet
held to the fire and been burned by millions or billions in lawsuits,
I suspect all of a sudden they would SEE a valid business reason where
none existed before. (Usual company disclaimers apply.)
Comments?
---
Kevin W. Wall Qwest Information Technology, Inc.
[EMAIL PROTECTED] Phone: 614.215.4788
"The reason you have people breaking into your software all
over the place is because your software sucks..."
-- Former whitehouse cybersecurity advisor, Richard Clarke,
at eWeek Security Summit
_______________________________________________
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
