harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Leo Li" <liyilei1...@gmail.com>
Subject Re: [classlib][security] BC provider as default Harmony crypto provider
Date Tue, 26 Jun 2007 12:58:37 GMT
Hi, Roman:
     I think it is reasonable to grant permissions to classes in extension
directory and RI has a similar line in its policy file.
     While I must admit that I have tried to delete this line in policy file
for RI 6.0 and there seems to be no problem to get instance from crypto
provider, I think it is due to the RI's security provider(SunJCE) does not
require some priviledge to work and it is the provider's freedom. (Spec does
not forbid providers to do this.)
     And Roman, is there an application fails due to this issue? If so, it
deserves us to find a solution.

On 6/26/07, Roman Bushmanov <roman.bushmanov@gmail.com> wrote:
>
> 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
>



-- 
Leo Li
China Software Development Lab, IBM

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