[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Default Policy
From: |
Casey Marshall |
Subject: |
Re: Default Policy |
Date: |
Fri, 12 Aug 2005 23:32:51 -0700 |
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.