* Java delenda est
@ 1996-04-10 15:13 David
0 siblings, 0 replies; 2+ messages in thread
From: David @ 1996-04-10 15:13 UTC (permalink / 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 ...
^ permalink raw reply [flat|nested] 2+ messages in thread
* Java delenda est
@ 1996-04-10 11:38 yarvin-norman
0 siblings, 0 replies; 2+ messages in thread
From: yarvin-norman @ 1996-04-10 11:38 UTC (permalink / raw)
[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
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~1996-04-10 15:13 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-04-10 15:13 Java delenda est David
-- strict thread matches above, loose matches on Subject: below --
1996-04-10 11:38 yarvin-norman
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).