From: David Lukes davel@morgan.com
Subject: Java delenda est
Date: Wed, 10 Apr 1996 11:13:49 -0400 [thread overview]
Message-ID: <19960410151349.4uYDhFYPvG0kJQI-qIO1W7J4KIak75d-M7byOvByKOs@z> (raw)
Sorry about the off-topicness of this,
but I think it's slightly warranted.
After this, can we all go back to discussing Plan9, please?
(Or maybe inferno, but NOT Burroughs and Java).
On Apr 10, 7:38, yarvin-norman@CS.YALE.EDU wrote:
> 1. The best way to handle Java security would be to do it in the
> operating system
Hear hear!
> The way Java security is currently done is a lot like
> the way security for normal programs was done on certain old
> Burroughs machines: there is no hardware protection which
> constrains Java programs, but instead the compiler is
> privileged software, which is trusted not to output bad code.
This is not quite accurate wrt Java.
On the B5000 et. al.,
the compiler DID take responsibility for the integrity of the whole system
by doing array bounds checking etc. etc. (*lots* of etc. etc.).
In java, the java loader takes on this responsibility,
verifying the bytecode before it's executed,
and relying on runtime checks for the remaining possible insecurities.
(If the security was in the compiler,
a malicious user could send down a hand assembled
java bytecode program to do whatever they liked).
> I'm not aware of what specific problems have been
> encountered either with the old Burroughs machines
How about compiler bugs crashing your system?
Thus compiler development required a tolerant user population,
a lot of midnight oil or a dedicated system.
As an aside,
since the file system needed to be strongly typed,
so that only a compiler could output executable files,
this gave rise to interesting problems when saving and restoring from tapes ...
> or with
> Java,
Netscape and/or Sun have already had at least one bug that allowed Joe User
to subvert Internet firewalls using java applets. (Cute name, eh?)
Fundamentally the 2 approaches are the same:
you have to trust some piece of complex and fallible software with
some part of your systems' safety,
and unless that piece of code and everything it depends on,
have been formally verified (yeah, right),
you will, at some point it time, lose,
when an exploitable bug appears.
(I'm not saying OSs are perfect,
but they keep all your security bugs in one place ...)
End of diatribe, back to normal programming.
Dave.
P.S. Personally, when I think of Java, I think of Krakatoa and boiling lava ...
next reply other threads:[~1996-04-10 15:13 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-04-10 15:13 David [this message]
-- strict thread matches above, loose matches on Subject: below --
1996-04-10 11:38 yarvin-norman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=19960410151349.4uYDhFYPvG0kJQI-qIO1W7J4KIak75d-M7byOvByKOs@z \
--to=9fans@9fans.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).