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
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath
|
_______________________________________________
Classpath mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/classpath
