classpath
[Top][All Lists]
Advanced

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

Re: Default Policy


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
  

_______________________________________________ Classpath mailing list address@hidden http://lists.gnu.org/mailman/listinfo/classpath

reply via email to

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