From: yarvin-norman@CS.YALE.EDU yarvin-norman@CS.YALE.EDU
Subject: Java delenda est
Date: Wed, 10 Apr 1996 07:38:49 -0400 [thread overview]
Message-ID: <19960410113849.ln8A5dKWUQJyPNx_PGrR-Pw-oV7aCR_j4g237xexQ90@z> (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
next reply other threads:[~1996-04-10 11:38 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
1996-04-10 11:38 yarvin-norman [this message]
1996-04-10 15:13 David
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=19960410113849.ln8A5dKWUQJyPNx_PGrR-Pw-oV7aCR_j4g237xexQ90@z \
--to=yarvin-norman@cs.yale.edu \
/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).