Security Aware Programming in Tuscany (TUSCANY) edited by haleh mahbod
Page:
http://cwiki.apache.org/confluence/display/TUSCANY/Security+Aware+Programming+in+Tuscany
Changes:
http://cwiki.apache.org/confluence/pages/diffpagesbyversion.action?pageId=80637&originalVersion=1&revisedVersion=2
Content:
---------------------------------------------------------------------
h1. Security Aware Programming in Tuscany.
{color:blue}
[*Java Security*| http://vcasmo.com/video/beckerdo/2750] is available in Video,
use tuscany passcode
{color}
h2. Introduction to Java Security
As you develop software for the *Apache Tuscany* project, it is important to be
aware and maintain the security features of the Java platform. Java's success
is promoted by its security architecture and relative absence from security
problems. Similarly, Tuscany will benefit as a platform if the developers take
care to keep it secure and free from ill-intentioned users.
This article focuses on the *security manager* and *access control* mechanisms
in the Java platform and the Tuscany code base. The focus here is not on SCA
applications and samples, but rather contributions that affect the Tuscany
runtime including any contributions or additions such as new bindings,
implementations, or data bindings. Taking advantage of the security manager and
limiting access to secure areas of the code base are the primary defense
against unsafe operation of Tuscany's SCA platform. And since Tuscany code is
available for anyone to read, it is important to prevent any unprivileged
access to the system on which Tuscany is running. This requires that developers
understand application runtime and server policies and how to guard the system
resources. Here is a good overview of [Java
Security|http://java.sun.com/javase/6/docs/technotes/guides/security/overview/jsoverview.html].
By default, Java application code and the Tuscany code base run in an unsecure
environment with no security manager. This gives the Java application access to
all system resources. The application may read and write all system properties,
open and read any system files, and do all sorts of unprotected actions. All
Tuscany code will run unhindered in this environment. And all malicious Tuscany
users will also run unhindered in this environment.
You may turn security on by running your Tuscany application with the
{{-Djava.security.manager}} option on the command line. The default security
manager delegates access control decisions to
{{java.security.AccessController}}. The {{AccessController}} determines access
authority for your Java code by consulting the permissions in a
{{java.security.Policy}} class usually specified in the default
{{security.policy}} file.
There is only one {{Policy object}} installed into a Java runtime at any given
time. The default behavior for Java is to load the authorization data from one
or more security policy files, but Tuscany users may add to or replace the
policy by running with additional policy information on the command line. For
instance {{"-Djava.security.manager -Djava.security.policy=tuscany.policy
-Dpolicy.allowSystemProperty=true"}} will add the permissions in the
tuscany.policy file to the default Java permissions. If you specify
{{"-Djava.security.policy==tuscany.policy"}} you replace the default policy
with those specified in the Tuscany policy file. When Tuscany is run by an
application server (whether it be WebSphere, Geronimo, or other), the policy of
the server will form the starting point for Tuscany's security policy.
Each policy file will contain a list of grant statements. A grant tells the
runtime where the code came from (a URL specifying the code base), who signed
the code (a list of signer certificates), and what permissions are given. The
permissions can be read write permissions to the file system, access to system
properties, or class loading privileges.
An example of a granting all permission to an unsigned Tuscany code base is
given here:
{code:title=security.policy example|borderStyle=solid}
grant codeBase "file:$/{{user.home}}/tuscany/java/sca/-" {
permission java.security.AllPermission;
};
{code}
This example grant statement is quite a broad bludgeon. Namely it says that all
Tuscany code has been granted all permissions. This is not much different that
running without a security manager. In practice, a user policy will want much
finer-grained permissions towards the Tuscany code and allow only specific
pieces of the code to have privileged access. The remainder of this article
shows how to locate those permissions and how to enable secure checks for them.
In summary, with security on, Tuscany class XYZ can access a secured resource
only if the security manager's {{AccessController}} has determined the proper
permissions are available in the security policy. Tuscany code that calls a
protected Java API will only work with an {{AccessController doPrivileged}}
block and the proper permissions in place. Otherwise, the Tuscany code will not
run properly with security on, and it will throw {{SecurityExceptions}} left
and right. Many times these {{SecurityExceptions}} will be passed back to the
Tuscany runtime and then be wrappered in a {{ServiceRuntimeException}} and
presented to the user. Not good.
h2. Common Java APIs That Require Security Enablement
What are some of the Java APIs that might cause your Tuscany code to produce a
{{SecurityException}}? In the [Java API
Reference|http://java.sun.com/javase/reference/api.jsp], any Java API that
throws a {{SecurityException}} is a candidate.
For instance, notice that
[{{java.lang.System.getProperty(String)}}|http://java.sun.com/javase/6/docs/api/java/lang/System.html#getProperty(java.lang.String)]
may throw a security exception. With security on, you are allowed to read some
{{System}} properties (such as {{java.version}} or {{os.name}}) but by default
you will get a {{SecurityException}} on other properties (such as {{user.home}}
or {{java.home}}). In general, this makes sense because we do not want any
intruders to have a map of the file system. A concise list of APIs with
security checks is located at [Methods and the Permissions They
Require|http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html#PermsAndMethods].
Whenever you use one of these security enabled Java APIs (any API with a
"{{throws SecurityException}}" suffix), you must do two things to ensure your
code will run with security on:
# Add the required permission to your Tuscany or application sever security
policy.
# Add an {{AccessController.doPrivileged}} call block around your code.
This section discusses identifying any necessary security permissions, and the
next session shows how to write {{AccessController}} call blocks.
To be a little more concrete to Tuscany developers, let's go through some
common API groups that they are likely to use.
# {{System.getProperty(String)}}. This is quite a common item to check to make
operating system or Java version specific code. If you use this API you need to
add {{java.util.PropertyPermission}} to the security policy. For example, this
permission allows the Tuscany code base to read two system properties:
{code:title=security.policy property read example|borderStyle=solid}
grant codeBase "file:$/{{user.home}}/tuscany/java/sca/-" {
permission java.util.PropertyPermission "user.home", "read";
permission java.util.PropertyPermission "java.home", "read";
};
{code}
# File IO. If you create a file stream, or attempt to check if a {{File}}
exists or is a directory, or can read or write, you will have to add
{{java.io.FilePermissions}}.
# ClassLoader. Anytime you access the ClassLoader via {{getClassLoader()}}
(which is common if you want to load a resource), you will have to add a
{{java.lang.RuntimePermission}}.
# Introspection. Whenever you do any sort of dynamic class loading and
execution, say you want to check for methods in a business interface, or you
want to instantiate a data object, you are going to add a
{{java.lang.RuntimePermission}}.
# URLS and sockets. Any sort of network access via {{URL}} streams or sockets
will have to be checked by the security manager. You will have to add
{{java.lang.RuntimePermission}} or {{java.net.SocketPermission}}.
# Threads. Any starting or stopping or checking for threads is going to be
guarded and you will have to have the proper {{java.lang.RuntimePermission}}.
# The Security stack. Need it be said, but if you attempt to access the
{{SecurityManager}}, {{AccessController}}, {{Policies}}, or other parts of the
security architecture you are going to need
{{java.security.SecurityPermission}}. In other words, hands off the security
system.
This list is just a general overview. Once again, any API that throws a
{{SecurityException}} is something that your Tuscany code should be privileged
and permitted to use.
h2. How to Write Access Control Blocks.
The final step of making your code security enabled is to add
{{AccessController}} privileged blocks around your enabled code. You must be
careful here. You cannot put a privileged block with a wide scope. That is
similar to running with security turned off. You also must be careful not to
grant privilege code that a malicious user could use. Be very careful of
granting privilege to any public API that a user can use with malicious
parameters. Here is a [more in-depth
article|http://java.sun.com/javase/6/docs/technotes/guides/security/doprivileged.html].
The type of coding pattern you use is based primarily on three considerations:
* the return type of the checked call
* the input parameters to the checked call
* the exceptions thrown by the checked call.
In the simplest case, let's say you use a checked Java API that throws no
exceptions other than {{SecurityException}}. (Recall that {{SecurityException}}
is thrown by all of these APIs.) For instance, your brand new Tuscany "Blatz"
extension needs to load the "blatz" library before it runs.
This is how you security enable the loading of the library.
{code:title=AccessController doPrivileged block - No
parameters|borderStyle=solid}
// ... unchecked code here...
AccessController.doPrivileged(new PrivilegedAction<Object>() {
public Object run() {
System.loadLibrary("blatz");
return null;
}
});
// ... more unchecked code here
{code}
Notice that the code is using the Java type safe syntax to ensure the proper
casting of the method run return type. The class in the <class specification>
should always match the return type class type.
In the next example, let us examine how a Java API with a boolean return type
is handled. Notice that we are using the autoboxing feature of Java to convert
from {{boolean}} to {{Boolean}}.
{code:title=AccessController doPrivileged block - With Return
Type|borderStyle=solid}
boolean isDirectory = AccessController.doPrivileged(new
PrivilegedAction<Boolean>() {
public Boolean run() {
return rootFolder.isDirectory();
}
});
{code}
Using this succinct anonymous class, you must make sure any input parameters
are final instances. This is a requirement of the Java syntax. If you have a
parameter that has undergone multiple assignments, you can easily create a
final version of that input parameter and pass it into the block.
{code:title=AccessController doPrivileged block - Input
Parameters|borderStyle=solid}
URL constructedURL = protocol;
constructedURL += pathName;
constructedURL += parameters;
final URL xsdURL = constructedURL;
URL definitionsFileUrl = AccessController.doPrivileged(new
PrivilegedAction<URL>() {
public URL run() {
return getClass().getClassLoader().getResource(definitionsFile);
}
});
{code}
Finally, if your checked Java API throws an exception, such as the
{{IOException}} shown here, you need to catch it and cast it to match any
checked exceptions on your method, or you need to add the
PrivilegedActionException to the throws signature of your method.
{code:title=AccessController doPrivileged block - With
Exceptions|borderStyle=solid}
InputStream is;
try {
is = AccessController.doPrivileged(new
PrivilegedExceptionAction<InputStream>() {
public InputStream run() throws IOException {
return url.openStream();
}
});
} catch ( PrivilegedActionException e ) {
throw (IOException) e.getException();
}
{code}
This article shows just a few techniques that cover many of the security issues
that arise in the Tuscany code base. If you are aware of the Java security
architecture and how to control access to guarded resources, you can guard
against malicious users who might use the Tuscany code base for no good.
---------------------------------------------------------------------
CONFLUENCE INFORMATION
This message is automatically generated by Confluence
Unsubscribe or edit your notifications preferences
http://cwiki.apache.org/confluence/users/viewnotifications.action
If you think it was sent incorrectly contact one of the administrators
http://cwiki.apache.org/confluence/administrators.action
If you want more information on Confluence, or have a bug to report see
http://www.atlassian.com/software/confluence
