Re: Default Policy

[Casey Marshall]

Hi, Mark,

On Aug 12, 2005, at 10:58 AM, 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?

Bug classpath/22853 prompted this, btw.

Kaffe and jamvm should (I posted patches for both of these); probably  
gcj (I posted a patch for this too, but it's been hit-or-miss on  
whether or not my GCJ patches are accepted); I think I remember  
reading that IKVM implements it; I looked at SableVM, but found it  
too opaque to put a patch together quickly.

But, then again, lack of AccessController support in a VM must be  
regarded as a grave bug in that VM.

> > 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.

You can assign different permissions based on installation path, so  
jar files in a trusted installation directory (what should that be?)  
can be given all permissions. Other JVMs seem to use '${java.home}/ 
lib/ext' as a standard location for installed extensions, but seems  
possibly very VM-dependent, and I'm sure every GNU/Linux distribution  
installs things in different, incompatible places.

> 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.

Sun's 'java' executable, on Linux at least, does not install a  
SecurityManager unless you define the property  
'java.security.manager,' so on a default invocation all code is given  
all (most?) permissions, since security checks are not performed. I  
always thought this was a goofy security model, but I suppose it is  
okay in the face of not having any standard way to install Java  
libraries and programs.

I remember discussion some time ago about supporting a similar thing  
in Classpath -- so if 'java.security.manager' is defined, but empty,  
we use the default security manager. If non-empty we take the value  
as a class that extends SecurityManager, and load and instantiate  
that as the security manager.