Boris, for the security-sensitive applications, there is appropriate
guard in place:
public SecurityManager() {
SecurityManager security = System.getSecurityManager();
if (security != null) {
security.checkPermission(RuntimePermission.permissionToCreateSecurityManager);
}
Class<?> type = Security.class; // initialize Security properties
if (type == null) {
throw new AssertionError();
}
}
I believe this is enough. In fact if the code has enough privileges to
modify such principal system properties, there might be even more
severe problems...
2006/11/24, Boris Kuznetsov <[EMAIL PROTECTED]>:
Proposed update will resolve the providers issue in the concrete case.
But it is not resolve the problem completely.
The posibility to load malicious 'java.security' file still exist
(after changing java.home system property before Security class
initilaization). So, the application may replace any security property
and policy file.
On 11/24/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
> +1
>
> 2006/11/24, Tim Ellison <[EMAIL PROTECTED]>:
> > Alexey Varlamov wrote:
> > > 2006/11/24, Tim Ellison <[EMAIL PROTECTED]>:
> > >> So how about we implement Security#registerDRLProviders() (maybe with a
> > >> method name change) to register:
> > >>
> > >>
security.provider.1=org.apache.harmony.security.provider.cert.DRLCertFactory
> > >>
> > >>
security.provider.2=org.apache.harmony.security.provider.crypto.CryptoProvider
> > >>
> > >> security.provider.3=org.apache.harmony.xnet.provider.jsse.JSSEProvider
> > >> security.provider.4=org.bouncycastle.jce.provider.BouncyCastleProvider
> > >>
> > >> Thoughts?
> > >> Tim
> > >
> > > Well, there is a number of other sensitive keys without hardcoded
> > > defaults, e.g. package.access, probably bunch of ssl.* keys. Therefore
> > > I presume it should be Security#defaultConfig() then.
> >
> > Sorry, I wasn't clear. There is already a method called
> > Security#registerDRLProviders() that does nothing. I suggest that we
> > implement it as I described above.
> >
> > There may well be other properties that need a default value, but they
> > would be fixed elsewhere -- presumably where they are used, in case the
> > file exists but does not define those properties any more.
> >
> > If you agree with the default providers I can make that change.
> >
> > Regards,
> > Tim
> >
> > --
> >
> > Tim Ellison ([EMAIL PROTECTED])
> > IBM Java technology centre, UK.
> >
>
--
Best regards,
Boris Kuznetsov
Intel Middleware Products Division
