Re: DII COE bars Ada -> Java compilation

Re: DII COE bars Ada -> Java compilation

[Robert A Duff]

"Marc A. Criley" <marc.a.criley@lmco.com> writes:

> To Ada to JBC compiler vendors:
> 
> Section 8.2.3 (Miscellaneous) of the Defense Information Infrastructure
> Common Operating Environment (DII COE) Integration & Run-Time
> Specification (I&RTS) v4.0 states that "Developers shall not use
> compilers designed to convert code developed in other languages (e.g.,
> Ada, C++) to create Java byte-codes. This restriction is important
> because such compilers may inadvertently bypass intended Java security
> features."
> 
> Is this a legitimate concern?

No.

- Bob

Re: DII COE bars Ada -> Java compilation

[Ted Dennison]

In article <38EB3482.971747E4@lmco.com>,
  "Marc A. Criley" <marc.a.criley@lmco.com> wrote:
> Specification (I&RTS) v4.0 states that "Developers shall not use
> compilers designed to convert code developed in other languages (e.g.,
> Ada, C++) to create Java byte-codes. This restriction is important
> because such compilers may inadvertently bypass intended Java security
> features."
>
> Is this a legitimate concern?  I can kinda see how it might be, since

I should hope not. If the security is built into the language rather
than into the virtual machine, then anyone could bypass the security
just by writing themselves a program in "bytecode assembly".

--
T.E.D.

http://www.telepath.com/~dennison/Ted/TED.html


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: DII COE bars Ada -> Java compilation

[David Starner]

>"Marc A. Criley" <marc.a.criley@lmco.com> writes:
>
>> Ada, C++) to create Java byte-codes. This restriction is important
>> because such compilers may inadvertently bypass intended Java security
>> features."

The point of such security is so that I can trust a random Java applet
sent across the net. Since I can't know what compiler made the applet,
or even if it was written in Java bytecode by hand, it would be pointless
if "such compilers" could bypass Java security.

-- 
David Starner - dstarner98@aasaa.ofe.org
Only a nerd would worry about wrong parentheses with
square brackets. But that's what mathematicians are.
   -- Dr. Burchard, math professor at OSU

Re: DII COE bars Ada -> Java compilation

[Robert Dewar]

In article <38EB3482.971747E4@lmco.com>,
  "Marc A. Criley" <marc.a.criley@lmco.com> wrote:

> Is this a legitimate concern?

No it is complete technical nonsense.

It would be reasonable to have a requirement that JBC programs
have been verified by some appropriate verifier, a requirement
that should then be applied to any JBC program.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: DII COE bars Ada -> Java compilation

[Robert Dewar]

In article <38EB3482.971747E4@lmco.com>,
  "Marc A. Criley" <marc.a.criley@lmco.com> wrote:

> Is this a legitimate concern?

No it is complete technical nonsense.

It would be reasonable to have a requirement that JBC programs
have been verified by some appropriate verifier, a requirement
that should then be applied to any JBC program.


Sent via Deja.com http://www.deja.com/
Before you buy.

DII COE bars Ada -> Java compilation

[Marc A. Criley]

To Ada to JBC compiler vendors:

Section 8.2.3 (Miscellaneous) of the Defense Information Infrastructure
Common Operating Environment (DII COE) Integration & Run-Time
Specification (I&RTS) v4.0 states that "Developers shall not use
compilers designed to convert code developed in other languages (e.g.,
Ada, C++) to create Java byte-codes. This restriction is important
because such compilers may inadvertently bypass intended Java security
features."

Is this a legitimate concern?  I can kinda see how it might be, since
for instance Java forbids things like uninitialized objects (though I
vaguely recall some kind of exception to that), which Ada permits.  I
suspect I could probably come up with some other potential problems if I
dug into it.

If the Ada to JBC compilers do not introduce the security risks that the
I&RTS warns about, some educating is clearly called for.

Marc A. Criley
Software Architect
Lockheed Martin M&DS
marc.a.criley@lmco.com

Re: DII COE bars Ada -> Java compilation

[Marc A. Criley]

Given the resounding repudiation of the this prohibition against Ada (or
other language) to Java compilers, I'd like to try to get it removed.

Though I'm not working on a DII COE compliant program, I'm going to try
to look at and work the process to get it removed.  If anyone
(particularly among those responding) has any technical material, white
papers, etc., with which to buttress this effort, I would be happy to
incorporate those into this drive.

Alternatively, if someone feels they're in a better position to attack
this issue now that it's been identified, I'll defer to and support
them.

Thanks for the responses.

Marc A. Criley
Software Architect
Lockheed Martin M&DS
marc.a.criley@lmco.com


"Marc A. Criley" wrote:
> 
> To Ada to JBC compiler vendors:
> 
> Section 8.2.3 (Miscellaneous) of the Defense Information Infrastructure
> Common Operating Environment (DII COE) Integration & Run-Time
> Specification (I&RTS) v4.0 states that "Developers shall not use
> compilers designed to convert code developed in other languages (e.g.,
> Ada, C++) to create Java byte-codes. This restriction is important
> because such compilers may inadvertently bypass intended Java security
> features."
> 
> Is this a legitimate concern?  I can kinda see how it might be, since
> for instance Java forbids things like uninitialized objects (though I
> vaguely recall some kind of exception to that), which Ada permits.  I
> suspect I could probably come up with some other potential problems if I
> dug into it.
> 
> If the Ada to JBC compilers do not introduce the security risks that the
> I&RTS warns about, some educating is clearly called for.
> 
> Marc A. Criley
> Software Architect
> Lockheed Martin M&DS
> marc.a.criley@lmco.com

Re: DII COE bars Ada -> Java compilation

[Wes Groleau]

> that Sun or Microsoft would stoop to this kind of action is probably
> very unlikely.  They are honorable people, as we all know.

Yet Janet says Bill is ambitious,
And Janet is an honorable woman.

How many will weep if Bill ends up like Julius?  (figuratively speaking)

Re: DII COE bars Ada -> Java compilation

[Wes Groleau]

> > .... such compilers may inadvertently bypass intended Java security
> > features."
> >
> > Is this a legitimate concern?  I can kinda see how it might be, since
> 
> I should hope not. If the security is built into the language rather
> than into the virtual machine, then anyone could bypass the security
> just by writing themselves a program in "bytecode assembly".

And in fact, one security report I read described a security hole that
could be exploited by a byte-code assembler but which was prevented by
a "correct" Java compiler.

Re: DII COE bars Ada -> Java compilation

[Robert I. Eachus]

"Marc A. Criley" wrote:
> 
> Given the resounding repudiation of the this prohibition against Ada (or
> other language) to Java compilers, I'd like to try to get it removed.
> 
> Though I'm not working on a DII COE compliant program, I'm going to try
> to look at and work the process to get it removed.  If anyone
> (particularly among those responding) has any technical material, white
> papers, etc., with which to buttress this effort, I would be happy to
> incorporate those into this drive.
> 
> Alternatively, if someone feels they're in a better position to attack
> this issue now that it's been identified, I'll defer to and support
> them.
 
    A few months ago, I would have been a good choice to carry the ball
on this.  However,
I have been out sick for several months, and may end up on long-term
disability.  I was diagnosed with fibromyalgia last fall, and it is not
clear whether I got knocked out by a case of the flu, or just by trying
to keep working full time.  In any case, I've been juggling medications
to come up with a mix that minimizes the pian while allowing me to
function mentally.  I'm making progress, and may soon catch up to
comp.lang.ada--from home.

    In any case, I will talk to the Air Force Program Office on this,
and I don't expect much argument from the Air Force.  (Although there
are good reasons for limiting the HLLs that can be used to generate
JBC.  No reason to allow a vendor to develop a private language and
compiler as a back door way of maintaing ownership.)  DISA is a
different story, and in any case moves much more slowly.

Re: DII COE bars Ada -> Java compilation

[swhalen]

Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:

:> > .... such compilers may inadvertently bypass intended Java security
:> > features."
:> >
:> > Is this a legitimate concern?  I can kinda see how it might be, since
:> 
:> I should hope not. If the security is built into the language rather
:> than into the virtual machine, then anyone could bypass the security
:> just by writing themselves a program in "bytecode assembly".

: And in fact, one security report I read described a security hole that
: could be exploited by a byte-code assembler but which was prevented by
: a "correct" Java compiler.

I suspect this same "security expert" would also say your house was
safe if burglars would use only "approved" breaking and entering tools
<g>.

Steve

-- 
{===--------------------------------------------------------------===}
                Steve Whalen     swhalen@netcom.com
{===--------------------------------------------------------------===}

Re: DII COE bars Ada -> Java compilation

[Richard D Riehle]

The DII policy is actually rather amusing.  I doubt anyone there
is technically astute enough to invent this policy.  Rather, they
were probably coached by someone from Sun or Microsoft.  I can
imagine a scenario where someone from Sun, having discovered an
Ada intruder, calls aside one of the managers and warns him/her 
of the potential for danger from this non-Java compiler.  We have
certainly seen other efforts to sabotage Ada when using it ran
contrary to the economic interests of some company with a competing
technology. When Ben & Jerry, the ice cream people were faced with 
restraint of trade from Pillsbury, they launched a humorous 
campaign, "What's the Doughboy afraid of?"   Of course, the thought
that Sun or Microsoft would stoop to this kind of action is probably
very unlikely.  They are honorable people, as we all know.

I guess it was just stupidity at DII.  Sighhhhhhhhhh.

Richard Riehle 
richard@adaworks.com

Re: DII COE bars Ada -> Java compilation

[Robert Dewar]

In article <38EDE91D.C6A9EC19@ftw.rsc.raytheon.com>,
  Wes Groleau <wwgrol@ftw.rsc.raytheon.com> wrote:
> And in fact, one security report I read described a security
> hole that could be exploited by a byte-code assembler but
> which was prevented by a "correct" Java compiler.

But that is the function of the byte code verifier. Obviously
unverified code is risky no matter *what* the source. One
certainly has far more faith in the verifier than in *any*
compiler.


Sent via Deja.com http://www.deja.com/
Before you buy.

Re: DII COE bars Ada -> Java compilation

[Wes Groleau]

> : And in fact, one security report I read described a security hole that
> : could be exploited by a byte-code assembler but which was prevented by
> : a "correct" Java compiler.
>
> I suspect this same "security expert" would also say your house was
> safe if burglars would use only "approved" breaking and entering tools
> <g>.

See http://www.cs.princeton.edu/sip/ and decide for yourself 
how "expert" these guys are.

-----------------

> > And in fact, one security report I read described a security
> > hole that could be exploited by a byte-code assembler but
> > which was prevented by a "correct" Java compiler.
> 
> But that is the function of the byte code verifier. Obviously
> unverified code is risky no matter *what* the source. One
> certainly has far more faith in the verifier than in *any*
> compiler.

Correct.  My point was:

1. The byte-code verifier apparently is NOT enough 
   for security.

2. For DoD to trust the JVM for security instead of
   conducting adequate reviews and tests would be
   just as  stupid as claiming Java is the only
   secure language.


-- 
Wes Groleau
http://freepages.genealogy.rootsweb.com/~wgroleau

Re: DII COE bars Ada -> Java compilation

[Robert Munck]

On Fri, 07 Apr 2000 00:48:11 GMT, Richard D Riehle
<laoXhai@ix.netcom.com> wrote:

>The DII policy [makers] were probably coached by someone
> from Sun or Microsoft.

Both are possible. Note, however, that the ruling could have been
intended to be pro-Java, anti-Ada, or anti-C++.  This introduces
a wide array of possible advocates of the rule both inside and
outside the DoD.  Given what I know of DISA and the COE, my
bet would be MITRE.

Note that DoD has all of the mechanism in place that it needs to
mandate (ahem) use of a standard language compiling to the
JVM.  By choosing instead a fad language that is not a standard
(and unlikely ever to be), they are making a very short-sighted
decision.

Bob Munck
Mill Creek Systems LC

Re: DII COE bars Ada -> Java compilation

[Robert I. Eachus]

Robert Munck wrote:

> Both are possible. Note, however, that the ruling could have been
> intended to be pro-Java, anti-Ada, or anti-C++.  This introduces
> a wide array of possible advocates of the rule both inside and
> outside the DoD.  Given what I know of DISA and the COE, my
> bet would be MITRE.

  You may be out of date, but for that matter, so could I.  However,
given the current structure, I would suspect JPL or INRIA.

Re: DII COE bars Ada -> Java compilation

[Geoff Bull]

Robert Munck wrote:
> 
> On Fri, 07 Apr 2000 00:48:11 GMT, Richard D Riehle
> <laoXhai@ix.netcom.com> wrote:
> 
> >The DII policy [makers] were probably coached by someone
> > from Sun or Microsoft.
> 
> Both are possible.

Probably not Sun, because the Java Security FAQ explicitly states
that using other languages will not affect security.

see:

http://java.sun.com/sfaq/#otherBytes

Re: DII COE bars Ada -> Java compilation

[Hal Hawley]

Speculation about the original source for the restriction against
other languages to Java byte code compilation might be useful in
understanding the non-technical (read "bureaucracy") aspects of how
to best get the restriction removed.

I don't see what the motivation would be for Sun, Microsoft, MITRE,
JPL, or INRI to have provided the original recommendation against
such compilation.  While I have my own speculations about which
organization "sponsored" the restriction, I hesitate to voice them
publicly, so will just let it go at saying I don't think anyone
has guessed correctly yet in the postings I've seen here.

There is a lot of bureaucracy overhead surrounding the DII COE, 
some of it being unavoidable (as in any large organization) and 
some being unnecessary.  In any event, I'm glad that someone has
taken the initiative to start the process of removing the
restriction, but expect the "wheels to grind slowly" in this
process.  

In the meantime, there is another process in place at DISA that
is relevant to this issue -- the waiver process -- at least as a
potential interim solution for those who are in need of an interim
solution.

-Hal Hawley
 Boeing, Phantom Works