Possible extension request: Solicited Policy ?

Lebin Cheng (lcheng@cheng1.corp.hp.com)
Fri, 9 Apr 1999 16:42:39 -0600 (MDT)

From: Lebin Cheng <lcheng@cheng1.corp.hp.com>
Message-Id: <199904092242.QAA06665@cheng1.corp.hp.com>
Subject: Possible extension request: Solicited Policy ?
To: java-security@java.sun.com
Date: Fri, 9 Apr 1999 16:42:39 -0600 (MDT)

Hi,

My name is Lebin Cheng. I am a Research Engineer of
Enterprise Business Infrastructure Services,
a corporate IT division, of Hewlett-Packard.

We are investigating the feasibility of
using signed Java Applets we developped for business
partner integration applications. We encounter
the following problem:

We would like to ask a business partner of HP, say
partner P, to adopt a Java Security Policy specific
for HP-signed applets. It will be something like:
grand signedBy "HP" {
permission ...
}

This policy must be general enough so that future applets
can be developped to take advantage of the privillage granded
by the policy without demanding exceptions to the policy
very often. In other words, this policy is potentially
super-set of all the permissions any HP applets would need
to do their jobs.

In addition, we would like to have only one HP signing certificate
to avoid confusing our business partners with multiple
HP signers and complex policies.

The problem is that, with such a policy in place, a Java applet
with the HP signature would have all the privillages (even the ones
it does not need for the task it is intended for) to potentially
cause damages. Due to this reason, no one is feeling comfortable
of managing the signing authority without the control of the Java
applet development.

To solve this problem, I am proposing an extension to the
Java 1.2 Security model: introduction of something I'd call
"solicited capability". Here is how it works:

When signing the JAR file, the signer ask the developer
soliciting the signature an additional list of privillages
the applet needs to complete its job. It can be written in
the same syntax as the Java policy file, with a little key
word change:
solicit signedBy "HP" {
permission java.io.FilePermission "c:\\tmp\\mylogfile"
}
The permissions must be "implied by" the general policy. The
signer then has the chance to examine this "solicited capabilities"
list and ensure that those capabilities are the ones necessary
for the applet to complete the intended task.

When the applet is downloaded to the client's desktop and
runs, the Java run-time not only check the local policy
for the applet, but also check the "solicited capabilities".
Only those privillage permitted by the policy *and* solicited
explicitly by signer (NOT the applet itself) are granded.

Benefits of the "solicited capabilities" extension are
summarized as follows:

1. Better implementation of the "Least Privillage Principle".
An applet does not automatically granded privillages because
it is signed by some highly trusted signer.
2. Relieve the receiver of applets from the burden of making
a tough trade-off between taking the risk of putting a
very general policy in place and managing a complex policy
covering every exception details.
3. Allow the signer some control over the code being signed.
Some might argue that the signer should never be burdened
with the code quality. However, the way Java Security
is architected and the fact that signer's principal is
used in policy makes the signer's signature much more powerful
than an integrity-protection.

To make the "solicited capability" feature works, current
Java AccessControl implementation may need to be extended.

Please feel free to contact me with your feedback. My
contact information is

Lebin Cheng
3000 Hanover St.
Palo Alto, CA94304
phone: 650-236-3979
email: lcheng@corp.hp.com

Regards,
--Lebin Cheng