9fans - fans of the OS Plan 9 from Bell Labs
 help / color / mirror / Atom feed
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 ...






             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).