Java delenda est

Java delenda est

[David]

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

Java delenda est

[yarvin-norman]

[Posting to comp.os.plan9 doesn't seem to work here; I'm trying mail to
9fans now.]

A while ago there was some talk on this newsgroup about a project named
Inferno, a Java competitor.  The following remarks are half speculation
and half opinion, which may or may not be relevant to Inferno; I have
no inside knowledge.

	1. The best way to handle Java security would be to do it in the
	operating system, that is, to run the Java code in a separate
	process which had no permission to do anything except
	communicate with its parent.
		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.
		I'm not aware of what specific problems have been
	encountered either with the old Burroughs machines or with
	Java, but a compiler is one of the most complicated pieces of
	software on the machine, as compared to memory protection
	hardware (and the OS software which manages it) which is
	simple, and in addition is already debugged.

	2. Under the versions of Unix I've seen, the operating system
	does not provide facilities by which a process can be deprived
	of all permissions except that of communicating with its
	parent.  One can make a start at it, by using chroot() and
	changing the userid to some completely unprivileged user, but I
	don't know any way to prevent the process from opening new
	TCP/IP connections.

	3. Plan 9 provides facilities to run a process in a namespace
	managed by the parent process, as done by iostats(4).  This can
	almost be used to cut the child process off from almost all
	possibility of doing damage.  The kernel still would still have
	to be changed so that new mounts could be disabled.  I think
	mounts of kernel devices, as in "bind #I /net", would be the
	main problem.

	4. If one took this approach, there'd be no point in using a
	specially crippled-for-security language like Java; one could
	just import C or Fortran code and compile and run it.



--
Norman Yarvin						yarvin@cs.yale.edu