|
From: | Ewout Prangsma |
Subject: | Re: Default Policy |
Date: | Sat, 13 Aug 2005 08:12:05 +0200 |
User-agent: | Mozilla Thunderbird 1.0.6 (Windows/20050716) |
Hi, JNode indeed runs with security always on. We have a custom Policy class, that does not read from disk by default, but from a stream that is passed on to its constructor. We also (currently) have a custom AccessController implementation. I hope to port that soon to the standard classpath implementation. Ewout Mark Wielaard wrote: Hi, On Mon, 2005-08-08 at 21:14 -0700, Casey Marshall wrote:Any opposition to changing the default security policy to gnu.java.security.PolicyFile? The current default policy is all- permissive to all code, which is a pretty bad policy (all code will work without security exceptions, but if something doesn't work because Classpath isn't using privileged actions appropriately, that should be considered a bug; I would rather err on the side of being too strict).Agreed that it would be good to see how well we are doing. Also JNode seems to always run with a security manager in place since Ewout often reports any issues we were missing. Now would be a good time to experiment whether or not this works since we are still some weeks from a next snapshot release (somewhere in the first/second week of September I hope). If it doesn't work out at all we can always disable it again by then. How many runtimes do support our default VMAccessController?If yes, Classpath should also come with a sensible default java.policy file. Any thoughts about what it should contain? I suppose it should be similar to the default policy that comes with most other Sun JREs, but I don't know if we can just use a copy of that one.We cannot just copy such things. Both from a legal and from a practical standpoint. Since our "restricted core classes" are obviously different so the security properties package.access and package.definition should be set to the appropriate gnu.classpath [gnu|java] entries I guess. According to my security book the default policy should mimic the old 1.1 access mechanisms for untrusted applets as close as possible. Which seems to be minimal SocketPermission for listening on the localhost interface and getting, but not setting PropertyPermission for file.separator and friends plus some java.* properties (probably the once we list under our java.lang.System.getProperties() documentation). And nothing much else. Which seems pretty restricted so programs cannot do much at all. Are you sure other implementations actually activate this default policy by default? I must get myself the new second edition Platform Security book. It might describe the default policy better. Cheers, Mark |
[Prev in Thread] | Current Thread | [Next in Thread] |