classpath
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Default Policy


From: Mark Wielaard
Subject: Re: Default Policy
Date: Fri, 12 Aug 2005 19:58:34 +0200

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
-- 
Escape the Java Trap with GNU Classpath!
http://www.gnu.org/philosophy/java-trap.html

Join the community at http://planet.classpath.org/

Attachment: signature.asc
Description: This is a digitally signed message part


reply via email to

[Prev in Thread] Current Thread [Next in Thread]