Agree On 11/24/06, Alexey Varlamov <[EMAIL PROTECTED]> wrote:
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 >
-- Best regards, Boris Kuznetsov Intel Middleware Products Division
