[4281] in java-interest
java-interest-digest V1 #242
daemon@ATHENA.MIT.EDU (java.sun.com!owner-java-interest-d)
Fri Dec 15 13:35:43 1995
From: java.sun.com!owner-java-interest-digest@asoft.msk.su
Date: Tue, 31 Oct 1995 23:30:07 -0800
To: java-interest-digest@java.sun.com
Reply-To: java.sun.com!java-interest@asoft.msk.su
java-interest-digest Wednesday, 1 November 1995 Volume 01 : Number 242
In this issue:
Invalidate Region
J*** Notes format error
write on a closed socket
Web security (was Please UNLOCK the power of Java)
Re> java-kerberos list... (fwd)
Looking for JAVA Audio info.
retarded problem and questin
Re: java-interest-digest V1 #240
When will JAVA finalize?
Calling Java from C
Q on static method reference to class
What object do "static synchronized" methods synchronize against?
Re: Q on static method reference to class
Re: Q on static method reference to class
native c mthds calling java mthds
----------------------------------------------------------------------
From: Aruna Kumar <Aruna_Kumar@ccm.jf.intel.com>
Date: Tue, 31 Oct 95 10:48:00 PST
Subject: Invalidate Region
Hi Folks,
How does one invalidate only a region in Java.
For example if on were writing solitaire in Java.
One would like to invalidate only the region covered by the card being
moved around rather than the entire client are.
Also, how to avoid the flicker of repainting.
Thanks.
Aruna
Aruna_kumar@ccm.jf.intel.com
------------------------------
From: mentor@io.org (David Forster)
Date: Tue, 31 Oct 1995 13:54:07 -0500
Subject: J*** Notes format error
Hi,
To anyone who looked at the Oct. 27th J*** Notes before Monday night with a
browser less forgiving than Netscape 1.1, my apologies. A header was
improperly closed off, causing most of the notes to be a "large print
edition!"
The error has been fixed.
From now on, I will be running the page first through Mark Gaither's
(markg@hal.com) html-check (note that the page now sports the proper
html-check logo at the bottom).
Cheers,
David Forster <br><a href="http://www.io.org/~mentor">
Mentor Software Solutions </a><br>
+1 905 832 4837 <br>
------------------------------
From: Anselm Baird_smith <Anselm.Baird_Smith@inria.fr>
Date: Tue, 31 Oct 1995 20:15:18 +0100
Subject: write on a closed socket
Hi,
What happens when a server write to some socket that the client has
closed (ie client process is dead) ? From what I can see things seems
to be quiet bad, here is the thread dump I get:
- -----
SIGQUIT 3* quit
Full thread dump:
"Thread-15" (TID:0xee3023b8, sys_thread_t:0xef3f0de8) prio=5
"Thread-14" (TID:0xee3005e8, sys_thread_t:0xef420de8) prio=5 *current thread*
java.net.SocketOutputStream.write(SocketOutputStream.java)
java.io.BufferedOutputStream.write(BufferedOutputStream.java)
java.io.PrintStream.write(PrintStream.java)
httpd.Client.loop(Client.java:252)
httpd.Client.run(Client.java:305)
java.lang.Thread.run(Thread.java)
"httpd" (TID:0xee301688, sys_thread_t:0xef450de8) prio=10
java.net.PlainSocketImpl.accept(PlainSocketImpl.java)
java.net.ServerSocket.accept(ServerSocket.java)
httpd.httpd.run(httpd.java:152)
java.lang.Thread.run(Thread.java)
"Event Manager" (TID:0xee301610, sys_thread_t:0xef480de8) prio=9
timers.EventManager.getNextEvent(EventManager.java:198)
timers.EventManager.run(EventManager.java:208)
"Finalizer thread" (TID:0xee300620, sys_thread_t:0xef4d0de8) prio=1
"Async Garbage Collector" (TID:0xee3005d0, sys_thread_t:0xef500de8) prio=1
"Idle thread" (TID:0xee300558, sys_thread_t:0xef530de8) prio=0
"clock handler" (TID:0xee300098, sys_thread_t:0xef5f0de8) prio=11
"main" (TID:0xee300048, sys_thread_t:0x77df0) prio=5
- -----
Thread-14 is *in* write, while the other end has closed the socket
(and even disappeared). The application (java) consumes an
tremendous amount of CPU. In brief things are down.
Any hint, sugestion well come.
Anselm.
------------------------------
From: David Hopwood <david.hopwood@lady-margaret-hall.oxford.ac.uk>
Date: Sun, 29 Oct 1995 21:08:34 GMT
Subject: Web security (was Please UNLOCK the power of Java)
[cc:ed to java-interest for those not yet reading comp.lang.java]
I wrote:
>This suggests that resources should be given out on a need-to-know basis.
>Then, the user can quantify the risks involved, and any damage is limited to
>the specific files or resources the app was trusted with.
Here is a scheme that implements this style of security (it's ended up a bit
longer than I anticipated, but never mind). Comments and criticism are
welcomed.
~~~~~~~~~~
There are two distinct kinds of access: by name, and by capability.
Names include filenames, directory names, device names, class names,
protocol names, etc. Any app can make up a name, e.g. "/etc/passwd", and
request access to it (but obviously this does not always succeed).
Importing a class counts as accessing it by name.
Capabilities are handles that provide a given level of access to a resource.
Unlike names, capabilities are unforgeable; a client that possesses one must
have obtained it directly or indirectly from a trusted source. There are two
kinds of capability: references, which are only valid in one address space and
for a single execution of an app, and persistent capabilities, which don't
have these restrictions.
Names and capabilities can be converted as follows:
<pre>
.----> Reference
/ ^
Name |
\ v
`----> Persistent
capability
</pre>
Converting from a name to a capability (of either kind) is strictly controlled.
Random applets from the net can only access harmless things by name (for
example, the GUI classes). Some apps are trusted to directly represent the
user (e.g. a GUI or a command-line shell), and can access any resource that
the user can. Signed apps would be given some intermediate level of access.
Converting between a persistent capability and a reference is usually allowed
(it may not be allowed if the capability was created with restrictions on its
use - see later). References point to objects and can be used directly.
This means it is possible for an app to use resources that it cannot access
by name, if it has been given a capability for them. For example, if I type
this on a command-line:
myapp 'foobar.html'
myapp will receive a capability for foobar.html (as well as its name as a
string). The quotes '' indicate to the shell that a capability should be
passed.
In a graphical environment, resource names would be entered in trusted
controls or dialogues. The control gets a resource name from the user, and
returns both a capability and the name to the app. If the app attempts to
create a spoof control, it will not gain any information that it could not
have gained using the real one.
(NB. it is important that trusted controls should always be redrawn correctly,
and that the app should not be able to draw over them).
The default permissions for a capability, e.g. read, write, execute etc. for
files, are determined by the security context (see later) for the app that
receives it. The defaults can be overridden by the user on a case-by-case
basis, by selecting options in a trusted control or by adding extra flags on
the command line.
An app can request to upgrade a capability to a higher access level (which may
involve prompting the user for confirmation). It can also downgrade it to a
lower access level - this is useful if it wants to pass the capability to
another app that it does not trust completely.
Rationale
~~~~~~~~~
Capability systems work on the following heuristic:
Telling someone about a private resource is almost always associated with
giving them access to it.
This applies to programs as well as people; for a program to access a resource,
at some point the resource's name must have been entered. So it is an attract-
ive idea to link authorization directly with the act of specifying a name.
The problem with this is that names are forgeable. For example, the name
"/etc/passwd" is well known - I don't have to have told it to an app before
it can request access to that file. But if it was possible to guarantee that
all names were distinct in some sense, so that I have to tell the app about my
_specific_ /etc/passwd, this could potentially provide a good degree of
security.
This is precisely what the capability-passing scheme above attempts to
simulate. Whenever I enter a resource name in a secure way, the relevant app
will get a corresponding capability. It doesn't matter that the app may not
have the rights needed to resolve the name itself.
Concrete example: a recent post in comp.lang.java mentioned accessing a
serial port. Suppose this port has the resource name 'driver:com1'.
For a shell: the user types something like "myapp port='driver:com1'"
For a GUI: myapp displays a trusted control showing a set of device icons,
and the user clicks one of them.
In either case, only access to 'driver:com1', and nothing else is granted.
Note that a capability can encapsulate any object; in this case the object
might enforce the use of a particular protocol, or handle device conflicts,
or whatever. At some point code must be calling the native OS, and that code
must be trusted completely. However the levels above that can potentially
be written as user classes.
This scheme does not always protect the user from him/herself, in that a
user can type in a name (perhaps at the prompting of the app), without
necessarily understanding what it means. It would be possible to display
warning dialogues for the most serious cases, though.
Applications and applets
~~~~~~~~~~~~~~~~~~~~~~~~
In the present API the distinction between these is quite sharp. I would
prefer to see a continuum of app*s, ranging from ImageLoop-type things
to full-blown editors, equation solvers, mail programs, etc.
Running all of these in a unified framework would greatly increase
the opportunity for co-operation between them (I'll expand on this in
another article).
In the framework I'm suggesting, applets are just apps with severely
restricted rights to access resources by name. It should also be possible to
write a shell or browser as an app, without having to treat it as a special
case.
Security contexts
~~~~~~~~~~~~~~~~~
Access levels are determined by security contexts. A security context holds
any available security information about a class or running app, for
example where it came from, whether it was signed and who by, whether it
has been installed persistently in a particular directory, etc.
It also stores a security policy (which can be assigned independently for each
app or class). The security policy is responsible for interpreting the other
information in the context to decide which requests are granted. (The interface
java.lang.SecurityManager in the beta API does something similar to this,
although I think it needs to be made much more flexible).
In more detail: security contexts are associated with both classes, and
thread groups (see the class java.lang.ThreadGroup). When a shell or browser
runs a program, it starts by running a method of a particular class. The
security context for that class is used as the security context for the thread
group.
A class can make each request for a resource using either its class security
context, or the current thread group context. This is similar to the
distinction between setuid programs and normal programs in Unix (except
that it applies to individual classes instead of users, and each request
instead of all a program's requests). For example, when an app uses a
trusted GUI control, the control uses its class context to look up the name
entered by the user. If it used the thread group context, the request would
probably be denied.
Implementing persistent capabilities
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
A persistent capability must have the following properties:
- - it specifies a unique resource and access level
- - it cannot be forged
- - it is 'just data' (a reference is not just data, because it has very
specific rules on how it can be manipulated, and is only unforgeable if
these rules are followed).
To meet these requirements, the capability must be chosen from a large
space of values, only a small (and unpredictable) fraction of which are
valid. Although in theory an attacker could guess the right one by luck,
this can be made arbitrarily unlikely.
One way of achieving this is to pair the resource name and access level
with a cryptographically secure random number. The run-time system
stores a table of these pairs, and checks on each access whether the correct
random number has been given. A capability can be revoked by removing
its entry from the table.
Another way is to digitally sign or encrypt the name and access level to
ensure it cannot be forged. (The choice between these is a tradeoff between
the checking time vs space for the table of pairs.)
A persistent capability can be associated with an 'acceptance condition' that
determines when it is valid (i.e. when it can be converted to a reference), and
what to do if it isn't.
For example, it is possible to create capabilities that are only valid for a
given length of time. Using the table implementation, this condition would
be stored in the table, e.g. as the predicate (current_time () < expiry_time).
These conditions don't have to be hardwired into the security system (e.g. as
user, group, world permissions are hardwired into Unix); they can be any
function of the capability, the security context (which includes the class and
app making the request), and the resource being accessed.
Secure persistent data
~~~~~~~~~~~~~~~~~~~~~~
A special case of an acceptance condition, could be to deny access to a
resource unless the requesting app is signed using a particular private key.
This is useful for controlling access to persistent data.
For an app to store persistent data, it must allocate a directory. Directories
are resources, so the app first prompts for the directory name using a trusted
dialogue. The resulting capability allows it to create the directory, and at
this point it can associate a public key with it. The app should be signed
using the corresponding private key.
Directories created in this way have quotas, and files created in them cannot
be symbolic or hard links to locations outside the directory.
Apps that are not signed with the appropriate private key cannot access the
directory by name (they may be able to access it via a trusted dialogue, i.e.
by asking the user nicely). This keeps apps partitioned from one another,
unless the user specifically requests it or the apps are signed using the same
private key.
Any app can request a list of the directories it is allowed to access by name,
but should not necessarily be able to see other directories.
Transferrability
~~~~~~~~~~~~~~~~
Since persistent capabilities are just strings of bits, they can be
duplicated, stored on disk, sent across the network, encrypted, signed, etc.
It also means they are potentially transferrable; if I email you a capability,
then all other things being equal, it will give you the same access to that
resource that I have.
For example, suppose I download an app from X, and give it a persistent
capability. Assuming the app is allowed network access, it can send this
capability back to X. X can email the result to Y, and when I download an
app from Y, it may be able to access the same resource.
This is sometimes a potential security hole, and sometimes very useful. The
question is whether trust is transitive, i.e. whether
A trusts X with R, and X trusts Y with R => A trusts Y with R
In general this depends what the resource, R, is. If it is read-only data,
then it is inevitable that Y will be able to access it, because the data
itself is copyable.
If the resource represents a service, or allows write access to something,
this is much less clear, and should probably be decided by A.
Fortunately the framework I've described can handle either option. It is
possible to 'stamp' a capability with information about who it was originally
given to (or any other information, in fact), so that removing the stamp
invalidates the capability - one way is to encrypt or sign the capability
after adding the information.
When a request using that capability is received from some other app, the stamp
can be used to decide whether to accept it.
Note that if capabilities are being transferred over the network, ideally the
channel should be encrypted, and both ends of the connection should be
authenticated.
Summary
~~~~~~~
Access to a resource is either by name or capability.
Names are forgeable; capabilities are not.
As well as files, names include directories, classes, protocols, etc.
Capabilities are either references, or are persistent. A capability can refer
to any object that encapsulates a resource.
A shell or GUI starts with access to all or most names (it is a trusted agent
of the user).
Apps from the net start with access to few harmless names.
An app can gain further access rights by being granted capabilities.
A shell grants a capability when the user enters a name on the command line.
A GUI grants a capability when the user enters a name in a trusted control
or dialogue.
There is a security context for each class, and each thread group.
When a thread group is started by calling a particular class, its security
context is used as the thread group security context.
The security context for the current thread group is used to determine default
access levels.
These access levels can be overridden when requesting each capability.
The access level for a capability can be upgraded or downgraded.
Persistent capabilities are implemented as (name, random key), or anything
else that encodes the name and is unforgeable.
Access conditions can be attached to a persistent capability, limiting when
it can be used.
Capabilities can be transferred between programs, either on the same system
or (if persistent) over the network.
It is possible to detect when a persistent capability has been transferred, by
stamping it with the user it was originally given to.
Although this scheme may sound complicated at first, most of the possibilities
arise from orthogonal combinations of a few basic ideas: capabilities, trusted
controls, and security contexts. For a different way of implementing
capabilities, see 'CACL: Efficient Fine-Grained Protection for Objects' in
OOPSLA (Object-oriented systems, languages and applications) 1992.
I will be implementing a prototype of this system; any help or suggestions
would be appreciated. One of the problems is that source for Sun's implement-
ation of the beta API has not yet been released (could anyone from Sun give
a date for this?).
David Hopwood
david.hopwood@lmh.ox.ac.uk
- -
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
- -
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
------------------------------
From: "Larry S. Bartz" <lsbart35@emmo.indy.cr.irs.gov>
Date: Tue, 31 Oct 1995 15:05:17 -0500 (EST)
Subject: Re> java-kerberos list... (fwd)
Responses to the message (looking for K-applet) I posted this A.M.
indicate there is considerable interest in this topic. Since I darkened
everyone's doorstep with my question, I'll share the best answer I've received
so far.
I've joined the java-kerberos list described below, where I hope we'll
carry on.
- --
#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
# Larry Bartz | |
# lbartz@infostream.cr.irs.gov | |
# | D'y'all want grits with that, |
# | Hon? |
# voice (317) 226-7060 | |
# FAX (317) 226-6378 | |
#:::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::|
- ---------- Forwarded message ----------
Message-Id: <199510311702.JAA00224@lindy.stanford.edu>
Date: 31 Oct 1995 08:58:52 -0700
> From: "Sid Conklin" <sid.conklin@nora.stanford.edu>
Subject: Re> java-kerberos list...
To: "lsbart35@emmo.indy.cr.irs.gov" <lsbart35@emmo.indy.cr.irs.gov>
Cc: "Tim Torgenrud" <torg@netserver.Stanford.EDU>
Larry,
I'm working on kerberizing Java applications and applets. We currently have
Kinit and components of Klist working for Version 4 of Kerberos. I plan on
distributing to the net after a few more GUI elements. The list that servers
this effort is java-kerberos@lists.stanford.edu. If you would like to
subscribe send the following message to majordomo@lists.stanford.edu
subscribe java-kerberos
Thanks for your interest,
Sid Conklin
Stanford University
------------------------------
From: michael@earthlight.com (Michael Slominski)
Date: Tue, 31 Oct 1995 12:10:31 +0800
Subject: Looking for JAVA Audio info.
I am looking for information on the JAVA's audio support. Can someone
point me to a description. I'd like to know:
* If java.applet.AudioClip/java.applet.Applet.getAudioClip can
currently only handle 8khz sample rate mu-law sound files. Is this
the case? If not, what audio file formats can be handle?
* If mu-law is it, what are the plans for supporting other (higher
fidelity) formats?
* Lastly, are there plans to support the use of "mixers" (perhaps
JAVA based)?
Again, is there documentation that discusses these issues? Thanks,
- -m
Slominski Consulting
408.738.1446
michael@earthlight.com
<URL::HTTP://earthlight.com>
------------------------------
From: Wayne Pinette <pinette@cs.sfu.ca>
Date: Tue, 31 Oct 1995 14:12:50 -0800 (PST)
Subject: retarded problem and questin
Ok, I have an applet which works fine when I view on a Solaris
box with sun's applet viewer. Now for reasons which are too
lengthy for me to go into, I need to run the same applet on
my W'95 box using netscape. Here is my question. Technically
speaking I should not have to recompile the byte code (correct?)
so I can ftp it to my machine. the problem here is this...it dont
work :-). I think my problems lie in the file name (the infamous
name too long :-( ie. my class calls on another class file )
is this the case? or will I have to recompile the byte code for
W'95 (needing to recompile does not make any sense to me). If
it is the name problem which I am guessing, how can I get the
name to be ErrorHandler.class instead of Error~1.cla which is what
it is now :-)
Wayner
------------------------------
From: Che-Jen Kuo <ckuo@chaph.usc.edu>
Date: Tue, 31 Oct 1995 14:59:04 -0800 (PST)
Subject: Re: java-interest-digest V1 #240
unscribe
------------------------------
From: richard@aisgfl.gct.com (Richard Ching {Medaphis})
Date: Tue, 31 Oct 1995 17:47:31 -0500
Subject: When will JAVA finalize?
Hi,
I understand that JAVA is under the beta now. Can any one tell me
when JAVA will be finalize? When will JAVA be available to third
party browser (such as netscape).
Any answer would be appreciated.
Thank you
Richard Ching
Imonics Orlando
------------------------------
From: BC Krishna <bc@futuretense.com>
Date: Tue, 31 Oct 95 23:27:58 -0500 (GMT)
Subject: Calling Java from C
Here's a really stupid question:
Is it possible to call Java from a C program?
There are a couple of specific scenarios:
1. A C-based application -- the owner of the main event loop -- wants to
have an applet run inside a window that it owns. How is this done?
2. A Java-based application wants call an asynchronous native method, which
calls back Java code at some later point in time. How is this done?
Thanks for your help.
cheers, bc
------------------------------
From: Bob Beck <rbk@ibeam.jf.intel.com>
Date: Tue, 31 Oct 95 17:06 PST
Subject: Q on static method reference to class
Suppose I want to refer to the class in a static method, eg to get the name
of the class, or create a new instance... How do I do this? If I'm in an
instance method, I can say (eg) "getClass().getName()". However, trying
various things in a static method gets compiler errors. Surely there must
be a way to do this cleanly without referring to the class by name?
- --
Bob Beck rbk@ibeam.intel.com CompuServe: 71674,106
Intel Corporation (503)264-8856 AOL: RDBeck
------------------------------
From: Bob Beck <rbk@ibeam.jf.intel.com>
Date: Tue, 31 Oct 95 17:08 PST
Subject: What object do "static synchronized" methods synchronize against?
I've verified that a method may be declared "static synchronized", and that
the synchronization works (ie, remove the "synchronized" attribute and it
races). Now I'm curious: what object does such a method synchronize
against? The class?
- --
Bob Beck rbk@ibeam.intel.com CompuServe: 71674,106
Intel Corporation (503)264-8856 AOL: RDBeck
------------------------------
From: Thomas.Ball@Eng.Sun.COM (Thomas Ball)
Date: Tue, 31 Oct 1995 17:48:26 -0800
Subject: Re: Q on static method reference to class
> Suppose I want to refer to the class in a static method, eg to get the name
> of the class, or create a new instance... How do I do this? If I'm in an
> instance method, I can say (eg) "getClass().getName()". However, trying
> various things in a static method gets compiler errors. Surely there must
> be a way to do this cleanly without referring to the class by name?
Implied in your question is the assumption that you can't just create
an instance of a class in one of its static methods, but you can:
public class test {
int num;
test(int num) {
this.num = num;
}
public static void main(String argv[]) {
test t = new test(123);
String name = t.getClass().getName();
System.out.println("class = " + name + ", object = " + t);
}
}
There is no easy way to divine that name from inside a static method
(unless you do the above), but then the class is already defined.
C has a similar feature when defining structs, where you can reference
that struct inside of itself (linked-lists are usually done that way).
Tom Ball
Java Products Group
------------------------------
From: Bob Beck <rbk@ibeam.jf.intel.com>
Date: Tue, 31 Oct 95 18:02 PST
Subject: Re: Q on static method reference to class
At 05:48 PM 10/31/95 -0800, Thomas Ball wrote:
>> Suppose I want to refer to the class in a static method, eg to get the name
>> of the class, or create a new instance... How do I do this? If I'm in an
>> instance method, I can say (eg) "getClass().getName()". However, trying
>> various things in a static method gets compiler errors. Surely there must
>> be a way to do this cleanly without referring to the class by name?
>
>Implied in your question is the assumption that you can't just create
>an instance of a class in one of its static methods, but you can:
>
>public class test {
> int num;
>
> test(int num) {
> this.num = num;
> }
>
> public static void main(String argv[]) {
> test t = new test(123);
> String name = t.getClass().getName();
> System.out.println("class = " + name + ", object = " + t);
> }
>}
>
>There is no easy way to divine that name from inside a static method
>(unless you do the above), but then the class is already defined.
>C has a similar feature when defining structs, where you can reference
>that struct inside of itself (linked-lists are usually done that way).
Thanks for the quick response! I was trying to avoid creating an instance
in the class method. This seems to be an area where Java isn't quite as
clean as (eg) Smalltalk ... in Smalltalk, a class method can refer to
"super" and things work as expected. Also, a class method can say (eg)
"self name" to get the name. Ie, the class is a "first class" object; it
doesn't seem quite true in Java...
There is a class object, but it doesn't seem wired into the method
resolution process quite right. Since an instance method can say getClass()
to get a reference to the class, why can't a class method do something to
get it? Intuitively, "this" in a class method would refer to the class.
>Tom Ball
>Java Products Group
- --
Bob Beck rbk@ibeam.intel.com CompuServe: 71674,106
Intel Corporation (503)264-8856 AOL: RDBeck
------------------------------
From: David Gourley <dgourley@cs.berkeley.edu>
Date: Tue, 31 Oct 1995 19:52:22 -0800
Subject: native c mthds calling java mthds
Hello,
This might be a naive question, but how would one go about having a native
method invoke a java class method. I have a c library that I would like to
have callback a java method I have written. Any help in how to go about
doing this would be appreciated.
- -david
------------------------------
End of java-interest-digest V1 #242
***********************************
-
This message was sent to the java-interest mailing list
Info: send 'help' to java-interest-request@java.sun.com
