# Re: Security manager & JRE

Marianne Mueller (Marianne.Mueller@eng.sun.com)
Thu, 18 Mar 1999 14:34:45 -0800 (PST)

- Messages sorted by: [ date ][ thread ][ subject ][ author ]
- Next message: Sohan Mendis: "Applet Security ?"
- Previous message: Kleban, Steve: "Security manager & JRE"
- Maybe in reply to: Kleban, Steve: "Security manager & JRE"

    Message-Id: <199903182234.OAA14640@shorter.eng.sun.com>

    Date: Thu, 18 Mar 1999 14:34:45 -0800 (PST)

    From: Marianne Mueller <Marianne.Mueller@eng.sun.com>

    Subject: Re: Security manager & JRE

    To: java-security@java.sun.com, sdkleba@sandia.gov

The best documentation for this is at
http://java.sun.com/products/jdk/1.2/docs/guide/security/index.html

You can replace the Policy class, not the SecurityManager,
but that's more work than needed. If you want to do this,
look for the documenation under "Changing the Policy
Implementation." You can specify the location of your policy
class via the property named policy.provider, in the java.security
properties file.

But, you don't need to rewrite the Policy class or the SecurityManager
class to allow unsigned applets to access the local disk. If you
don't specify "signedBy" or "codeBase", then the permission is
granted to all. For example, if you add this permission to the
Sandia policy file

grant codeBase "http://sandia.gov/-" {
permission java.io.FilePermission "/etc/passwd", "read"
}
then anyone coming from inside Sandia could read /etc/passwd. Presumably you
don't want to do that, but it's just by way of example. Other people
would not be able to access that file. You could say

grant {
permission java.io.FilePermission "/etc/passwd", "read"
}

and then everyone could read /etc/passwd.

A permission like this
grant codeBase "http://server.sandia.gov/-" {
permission java.io.FilePermission "<< ALL FILES>>", "read"
}

would let Sandia people who are using the web server named
"server.sandia.gov" read everything. This isn't really recommended,
but, it's up to you or the person who sets the internal security
policy.

The policy files are very configurable and we think you'd have a lot
better flexibility and auditability by using the policy files, rather
than by changing code.

If you are thinking about rewriting the SecurityManager, then you would require
your users to get your copy of JRE1.2. So it wouldn't be any
different to require your users to get your copy of JRE1.2 complete
with your java.security file, and then they'd get the updated policy.

The best way to do this is to use the java.security file to tell
the JRE where to find the system policy file. So you'd change
these lines in the $JAVA/lib/security/java.security file:

# The default is to have a single system-wide policy file,
# and a policy file in the user's home directory.
policy.url.1=file:${java.home}/lib/security/java.policy
policy.url.2=file:${user.home}/.java.policy
You would have policy.url.1 point to YOUR policy file, and if you
wanted to, you could delete the line policy.url.2. Then make
sure everyone gets your version of the JRE with this updated
java.security file.

The intent is for people who set the security policy to define and
make available the system-wide policy file. You can place that
file in a secure location, and keep tabs on it via a crontab job
that checks to see if a file's been tampered with, and so on.

Marianne

- Next message: Sohan Mendis: "Applet Security ?"
- Previous message: Kleban, Steve: "Security manager & JRE"
- Maybe in reply to: Kleban, Steve: "Security manager & JRE"