Date: Thu, 20 Feb 1997 09:43:20 -0800
Message-Id: <199702201743.JAA28447@puffin.eng.sun.com>
From: Marianne Mueller <mrm@eng.sun.com>
To: bryan.weingarten@CyberSafe.COM
Subject: Re: AppletSecurity.class
> We are a security company, and our customers don't trust or don't except
> the current security policy's in IE or Navigator. These security managers
> are not rigid enough and too flexible. We need to tighten things up a bit.
> Our customes will only trust Java if we give it our OK. And we can solve
> our problems with our own security manager in place.
Are you developing Java applications, or applets?
If applets, for now, you are stuck with the policy implemented in the
Security Manager of the browser that people are using. That's what I
meant by rigid. I didn't mean "rigid" in the sense of "it's like a
big strong brick wall" but rather "rigid" in the sense that it can't
today be configured to be more strict (or allow less access).
We want to fix that aspect, so that Java applications can be
configured to be more strict, or less strict, as makes sense for the
application and environment.
> Does the signed Java applets only allow what applets can be run in the
> sandbox, or can it additionally control how the applets can play in the
> sandbox? This is what we plan on doing by writing our own security
> mananger. For example, all applets signed by Sun can read and write to the
> hard disk, but all applets signed by another company can only read files,
> and another can't read or write. If signed applets only controls who
> plays, then it doesn't solve our problem.
In JDK 1.1, signing is "all or nothing" in the appletviewer. that is,
a signed applet is given full access. I suspect that is not what
you want.
In future releases, there will be configurable finer-grain access
control, so that you can set it up so that an applet signed by
CheckPointBalancersPro can access the checkbook database, but, not be
allowed any other access.
So the answer to your question is "both" but we're not there yet;
we're on that path.