From mboxrd@z Thu Jan  1 00:00:00 1970
Date: Wed, 10 Apr 1996 07:38:49 -0400
From: yarvin-norman@CS.YALE.EDU yarvin-norman@CS.YALE.EDU
Subject: Java delenda est
Topicbox-Message-UUID: 42c4b824-eac8-11e9-9e20-41e7f4b1d025
Message-ID: <19960410113849.ln8A5dKWUQJyPNx_PGrR-Pw-oV7aCR_j4g237xexQ90@z>

[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