harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Roman Bushmanov" <roman.bushma...@gmail.com>
Subject [classlib][security] BC provider as default Harmony crypto provider
Date Tue, 26 Jun 2007 12:21:49 GMT
Hi, all!

I would like to raise a question concerning our specifics in using Bouncy
Castle as default crypto provider.
I can't say definitely that we have a bug here but it would be great to hear
from our security gurus on this subject.

The point is that a security provider can be initialized correctly only by
trusted code i.e. application working w/out security manager or application
with certain security permission granted. For example,
java.security.SecurityPermission putProviderProperty.BC permission is
required by BC provider to be granted to initialize properly.

The problems appear because of dynamic initialization of security providers
in Harmony. In other words a provider is being initialized at the first
request by the application code which is not considered as trusted. To
address this issue, our implementation has the following statement in the
default policy file

grant codeBase "file:${java.home}/lib/ext/*" {
    permission java.security.AllPermission;
};

In my opinion, this is not an ideal solution to the problem. If someone
redefines the default policy file at runtime with -
Djava.security.policy==my.policy and does not include in my.policy the above
statement, the crypto provider will not work. That means the user should
know the specifics of our implementation and should tune his or her policy
files to work on our java. At the same time, RI doesn't have
such limitation.

As a possible solution I can suggest to change the implementation to always
grant the mentioned permission, not depending on the policy file.

Thank you,
Roman

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message