Tomcat Web Hosting Blog - Java, JSP, EJB, Hibernate

Chapter 14: Tomcat Security // These permissions apply to the logging API grant codeBase file:${catalina.home}/bin/tomcat-juli.jar { permission java.security.AllPermission; }; // These permissions apply to the server startup code grant codeBase file:${catalina.home}/bin/bootstrap.jar { permission java.security.AllPermission; }; // These permissions apply to the servlet API classes // and those that are shared across all class loaders // located in the lib directory grant codeBase file:${catalina.home}/lib/- { permission java.security.AllPermission; }; System Properties Access Permissions Tomcat grants read-only access (to Web applications running within the Tomcat server instance) to various system properties and other miscellaneous permissions as commented here: // ========== WEB APPLICATION PERMISSIONS ===================================== // These permissions are granted by default to all web applications // In addition, a web application will be given a read FilePermission // and JndiPermission for all files and directories in its document root. grant { // Required for JNDI lookup of named JDBC DataSource s and // javamail named MimePart DataSource used to send mail permission java.util.PropertyPermission java.home , read ; permission java.util.PropertyPermission java.naming.* , read ; permission java.util.PropertyPermission javax.sql.* , read ; // OS Specific properties to allow read access permission java.util.PropertyPermission os.name , read ; permission java.util.PropertyPermission os.version , read ; permission java.util.PropertyPermission os.arch , read ; permission java.util.PropertyPermission file.separator , read ; permission java.util.PropertyPermission path.separator , read ; permission java.util.PropertyPermission line.separator , read ; // JVM properties to allow read access permission java.util.PropertyPermission java.version , read ; permission java.util.PropertyPermission java.vendor , read ; permission java.util.PropertyPermission java.vendor.url , read ; permission java.util.PropertyPermission java.class.version , read ; permission java.util.PropertyPermission java.specification.version , read ; permission java.util.PropertyPermission java.specification.vendor , read ; permission java.util.PropertyPermission java.specification.name , read ; permission java.util.PropertyPermission java.vm.specification.version , read ; permission java.util.PropertyPermission java.vm.specification.vendor , read ; permission java.util.PropertyPermission java.vm.specification.name , read ; permission java.util.PropertyPermission java.vm.version , read ; permission java.util.PropertyPermission java.vm.vendor , read ; permission java.util.PropertyPermission java.vm.name , read ; // Required for OpenJMX permission java.lang.RuntimePermission getAttribute ; // Allow read of JAXP compliant XML parser debug permission java.util.PropertyPermission jaxp.debug , read ;

For high quality java hosting services please check java web hosting website.

Chapter 14: Tomcat Security On Windows systems, the command is quite similar: > TOMCAT_INSTALLATIONbincatalina start -security Tomcat s Policy File Tomcat uses the $CATALINA_HOME/conf/catalina.policyfile to determine its own permissions and those of its Web applications. What follows is the file as of Tomcat 6. Note that it is divided into three sections: system code permissions, Catalina code permissions, and Web application code permissions. System Code Permissions Tomcat s policy file grants all permissions to the javactool, which is used to compile JSPs into servlets, and grants all permissions to any Java standard extensions. Four grant lines are used instead of two to deal with multiple path possibilities. Note that administrators may need to add additional grants to this section if the JRE used to run Tomcat uses different paths for its standard extensions (such as Mac OS X) and Tomcat Web applications are using JARs or classes in those paths. // ========== SYSTEM CODE PERMISSIONS ========================================= // These permissions apply to javac grant codeBase file:${java.home}/lib/- { permission java.security.AllPermission; }; // These permissions apply to all shared system extensions grant codeBase file:${java.home}/jre/lib/ext/- { permission java.security.AllPermission; }; // These permissions apply to javac when ${java.home] points at $JAVA_HOME/jre grant codeBase file:${java.home}/../lib/- { permission java.security.AllPermission; }; // These permissions apply to all shared system extensions when // ${java.home} points at $JAVA_HOME/jre grant codeBase file:${java.home}/lib/ext/- { permission java.security.AllPermission; }; Catalina Code Permissions Note that Catalina grants all permissions to the following: . Tomcat s startup classes ( ${catalina.home}/bin/commons-daemon.jarand ${catalina .home}/bin/bootstrap.jar) . Classes from the logging API ( ${catalina.home}/bin/tomcat-juli.jar) . Shared files between class loaders ( $CATALINA/lib) // These permissions apply to the daemon code grant codeBase file:${catalina.home}/bin/commons-daemon.jar { permission java.security.AllPermission; }; (continued)

If you looking for unlimited one inclusive web hosting plan please check unlimited web hosting website.

Chapter 14: Tomcat Security Permission Class Description javax.security.auth .AuthPermission javax.security.auth.and PrivateCredentialPermission javax.security.auth.kerberos. and DelegationPermission javax.security.auth.kerberos. and ServicePermission javax.sound.sampled .AudioPermission Controls authentication permissions. Controls various security permissions. Controls various security permissions related to the Kerberos protocol. Controls various security permissions related to the Kerberos protocol. Controls access to the sound system. Enabling the Security Manager System The Security Manager system is enabled by passing the -Djava.security.managerparameter to the Java Virtual Machine at startup, in the following manner: $ java -Djava.security.manager MyClass By default, Java looks for the file $JAVA_HOME/lib/security/java.policy to determine what permissions to grant when the Security Manager is turned on. For more information on enabling the Security Manager and using custom policy files, see the following URL: http://java.sun.com/javase/6/docs/technotes/guides/security/PolicyFiles.html Advanced Security Manager Topics Some additional Security Manager topics are simply beyond the scope of this chapter. For example, it is possible to subclass the default Java Security Manager implementation to provide for custom permission classes. It is further possible to define grant blocks in policy files based on code signatures. For information on these and other advanced topics, check out the following URL: http://java.sun.com/javase/6/docs/technotes/guides/security/ Using the Security Manager with Tomcat Now that we ve covered the basics of the Security Manager system, we ll explain their use with Tomcat. Enabling Tomcat s Security Manager The preferred way to start Tomcat with the Security Manager enabled on Linux systems is as follows: $ TOMCAT_INSTALLATION/bin/catalina.sh start -security

For high quality java hosting services please check java web hosting website.

Chapter 14: Tomcat Security are also available with Java SE 5. The complete list of permission classes and their targets can be viewed at the following URL: http://java.sun.com/javase/6/docs/technotes/guides/security/permissions.html : Permission Class Description java.security.AllPermission java.security .SecurityPermission java.security .UnresolvedPermission java.awt.AWTPermission java.io.FilePermission java.io .SerializablePermission java.lang.reflect .ReflectPermission java.lang.RuntimePermission java.net.NetPermission java.net.SocketPermission java.sql.SQLPermission java.util.PropertyPermission java.util.logging .LoggingPermission javax.net.ssl.SSLPermission By granting this permission, all other permissions are also granted. Granting this permission is the same as disabling the Security Manager for the affected code. Allows programmatic access to various security features of the Java language. This permission class is not defined in policy files. Rather, it is used as a placeholder when a policy file makes reference to a user-defined permission class that had not been loaded at the time of processing the policy file. This permission is relevant only to those interacting with the Security Manager system programmatically at runtime. Controls various AWT permissions Restricts read, write, execute, and delete access to files in specified paths. Allows serialization permissions. Allows applications to circumvent the publicand private mechanism s access checks and reflectively access any method. Allows access to key runtime features (such as creating class loaders, exiting the VM, and reassigning STDIN, STDOUT, and STDERR). Allows various network permissions. Allows incoming socket connections, outgoing connections, listening on ports, and resolving host names. These permissions can be defined for specific host names and port combinations. While this may sound intriguing, it controls only a single permission: setting the JDBC log output writer. This file is considered sensitive because it may contain usernames and passwords. Controls whether properties can be read from or written to. Allows the capability to configure the logging system. Allows the capability to access SSL-related network functionality. Table continued on following page

For high quality jboss hosting services please check jboss web hosting website.

Chapter 14: Tomcat Security Note that comments in policy files must begin with // on each line. As shown in the first grantentry earlier, the codeBaseattribute is optional. codeBase specifies a URL to which all the permissions should apply. The syntax is shown in the following table. codeBase Example Description file:/C:/myapp/ http://java.sun.com/* file:/funstuff/Indicates that code in the directory c:myappwill be assigned the permissions in the grantblock. Note that the slash (/) indicates that only class files in the directory will receive the permissions, not any JAR files or subdirectories. All code from the specified URL will be granted the permissions. In this case, the /* at the end of the URL indicates that all class files and JAR files will be assigned the permissions, but not any subdirectories. All code in the /funstuff directory will be granted the permissions. The slash (/-) indicates that all class files and JAR files in the directory and its subdirectories will be assigned the permissions. Within the grant block, one or more permissions can be assigned. Each permission consists of a permission class name and, in some cases, an additional target that identifies a specific permission within the permission class. Some permission targets can additionally take parameters, called actions. Following are some examples of permissions: grant { // allows applications to listen on all ports permission java.net.SocketPermission localhost , listen ; // allows applications to read the java.version property permission java.util.PropertyPermission java.version , read ; } Available Permissions Permissions are defined by special classes that ultimately inherit from the abstract class java.security .Permission. Most permission classes define special targets that represent a security permission that can be turned on and off. For example, the java.lang.RuntimePermission class defines the targets shown in the following table. (Note that this is not a complete list.) Target Name Description createClassLoader exitVM.{n} Allows an application to create a custom class loader Allows an application to exit the JVM via the System.exit(n)method As of Java SE 6, there are 19 different permission classes offering control over various permissions. The following table shows a partial list of these classes to demonstrate the breadth of what is possible with permissions. This list is not an exhaustive listing of all possible permission targets. All of the permissions

For high quality java hosting services please check tomcat web hosting website.

Chapter 14: Tomcat Security This security architecture is turned off by default, but it can be turned on at any time. In this section, we review the Security Manager architecture in general terms. This is followed by a discussion of how this architecture specifically applies to Tomcat. Overview of the Security Manager As with the file system, the Security Manager architecture is based on the concept of permissions. Once the Security Manager is turned on (using a command-line switch that will be discussed shortly), applications must have explicit permission to perform certain security-sensitive tasks (such as creating a custom class loader or opening a network socket). To make effective use of the Security Manager architecture, it is therefore necessary to know how to grant permissions to applications and to understand the set of possible permissions. Granting Permissions to Applications Policy files are the mechanism used by the Security Manager to grant permissions to applications. Policy files are simple text files composed of individual actions that applications are allowed to perform. Note that the term applications in this context refers to applications running in the Java VM, of which the Tomcat server is a member. This is not referring to the Web applications that run within a Tomcat server instance. A policy file is composed of grantentries, which look like the following: // first grant entry grant { permission java.lang.RuntimePermission stopThread ; } // second grant entry grant codeBase file:${java.home}/lib/ext/* { permission java.security.AllPermission; }; The first grantentry in this example demonstrates the simplicity of the syntax. It grants all applications the capability to access the deprecated Thread.stop()method. The second grantentry illustrates that code in specific locations can also be granted permissions. This is, of course, useful for extending permissions to certain trusted code while denying permissions to all other code. In this case, all code in the $JAVA_HOME/lib/ext directory is granted all permissions, which effectively disables the Security Manager architecture for that code. Grant Entry Syntax Each grantentry must be composed of the following syntax: grant codeBase URL { // this is a comment permission permission_class_name target_name , action ; … };

If you looking for unlimited one inclusive web hosting plan please check cheap web hosting website.

Chapter 14: Tomcat Security user who needs to use Java, which can become tedious. This illustrates the utility of creating a series of groups that have access to certain areas of the file system. For example, users who need access to Java can be given membership in the Java Users group. Users who need the capability to manipulate the contents of the Java directory can be given membership in a group called Java Developers. The extra time required to configure such a setup can be well worth the added security and scalability as more users are added. The tomcataccount also needs access to the tomcat directory. These permissions can be granted with the same procedure used to grant access to the Java directory. For maximum security, grant only read access to the following directories: TOMCAT_INSTALLATION/bin TOMCAT_INSTALLATION/lib TOMCAT_INSTALLATION/webapps Note that TOMCAT_INSTALLATION/conf must have write permissions to function if Tomcat s default UserDatabase implementation is used for user authentication. In addition, note that making the TOMCAT_INSTALLATION/webapps directory read-only can cause problems if Web applications modify files in their directories, or if the Tomcat manager application is used to deploy new Web applications. Linux File System Securing the Linux file system requires two steps: granting the tomcat account read and execute permissions on the JRE directory (recursively), and granting it read, write, and execute permissions on the Tomcat directory. There are numerous ways to grant these permissions. Following is one strategy: . Recursively set the other permissions on the JRE directory to read and execute with the chmod command: chmod -R o=rx * . Recursively set the owner of the Tomcat directory to the tomcat account: chown -R tomcat: tomcat * For additional security, the owner, group, and other permissions for the following Tomcat directories can be set to read-only: . TOMCAT_INSTALLATION/bin . TOMCAT_INSTALLATION/lib . TOMCAT_INSTALLATION/webapps Note that TOMCAT_INSTALLATION/conf must have write permissions to function if Tomcat s default UserDatabase implementation is used for user authentication. In addition, note that making the TOMCAT_INSTALLATION /webapps directory read-only can cause problems if Web applications modify files in their directories, or if the Tomcat manager application is used to deploy new Web applications. Securing the Java Virtual Machine Configuring the file system for maximum security is an important part of securing an installation of a Tomcat server instance. Java s Security Manager architecture exposes an entirely different level of configurability. With the Security Manager, Java applications can be restricted from accessing features of the Java language and platform in a remarkably fine-grained manner.

If you looking for unlimited one inclusive web hosting plan please check unlimited web hosting website.

Chapter 14: Tomcat Security groups and the operations that the users/groups are permitted to perform. The set of allowed operations for a user or group is that entity s permissions. By default, Windows allows all users to access any resource in the file system, with the exception of sensitive areas, such as the Windows directory itself and the profile resources of other users. For the purposes of securing a Tomcat installation, these permissions are too liberal. The instructions in this section are intentionally minimal because this blog is not intended for use as a Windows administration guide. Restricting Permissions To accomplish the stated goal of reducing tomcat s permissions to the minimum required, all default permissions granted to the account must be revoked. To do this, the tomcataccount must be explicitly denied access to every resource in the file system, and then selectively granted access to the necessary resources. Use the following steps to revoke tomcat s permissions: 1. Right-click the first drive partition in the My Computer window. 2. Select the Properties context menu item. 3. Select the Security tab. 4. Click the Add button. 5. Select the tomcataccount. 6. Click every Deny check box. 7. Click the Advanced button. 8. Select the Reset permissions on all child objects and enable propagation of inheritable permissions check box. 9. Click OK. 10. Wait while Windows modifies every ACL in the partition s file system. 11. Repeat these steps with all partitions. Granting Permissions To do its job, the tomcat account must have permission to read and execute the JRE files. Thus, the next step in the process is to grant these permissions to the tomcataccount. This is accomplished by a similar process to the one discussed previously. To start, select the directory containing the JRE used to run Tomcat, and view the Security properties of the directory. The tomcat account should be present in the list of groups and users. Removing the tomcat account with the Remove button is sufficient to grant access to run Tomcat. Propagating this change to all child objects is also necessary using the same process discussed previously. For maximum security, the Everyone group should be removed from the JRE directory s ACL, and the tomcatuser should be added to it, and given only the following permissions: Read & Execute, List Folder Contents, and Read. However, this necessitates explicitly granting these permissions to every

For high quality website hosting services please check java web hosting website.

Chapter 14: Tomcat Security A typical configuration might use a script such as the following in /etc/init.d (or wherever init scripts are stored): #!/bin/bash RETVAL=$? export JAVA_HOME=/usr/java/jdk160 export CATALINA_HOME=/usr/local/tomcat6 case $1 in start) if [ -f $CATALINA_HOME/bin/startup.sh ]; then echo $ Starting Tomcat /bin/su tomcat $CATALINA_HOME/bin/startup.sh fi ;; stop) if [ -f $CATALINA_HOME/bin/shutdown.sh ]; then echo $ Stopping Tomcat /bin/su tomcat $CATALINA_HOME/bin/shutdown.sh fi ;; *) echo $ Usage: $0 {start|stop} exit 1 ;; esac exit $RETVAL You can the configure the script in /etc/init.d to load on startup by creating links to it in the desired run- level directories or by using a graphical configuration client, depending on the distribution of Linux used. Securing the File System Configuring a Tomcat server instance to run with its own user account is useful only if the account has most of its access privileges reduced, preventing havoc from being wreaked. Effectively, this means reducing the scope of the account s file system permissions to the minimum set required to perform the job. Windows File System Windows has two different types of file systems: FAT32 and NTFS. FAT32 is inherently insecure and can t be locked down. It is, however, an excellent choice for system administrators if instability, limitations, and inefficiency are considered virtuous. NTFS, conversely, has all the necessary features for restricting the tomcat user s capabilities. The type of file system being used can be determined by viewing the properties of the hard drive partition in question in the My Computer window. Windows supports upgrading FAT32 partitions to NTFS. Note, however, that once a partition has been changed to NTFS, it cannot revert back to FAT32. Access Control Lists NTFS security is built around the concept of access control lists (ACLs). Every resource in the file system (that is, files and directories) has an ACL that is associated with it. The ACL contains a list of users and

If you looking for unlimited one inclusive web hosting plan please check unlimited web hosting website.

Chapter 14: Tomcat Security Creating a Non-Privileged Tomcat User The first step in the process is to create an account for running Tomcat. For simplicity, this account is referred to as tomcat in the remainder of this section. Be sure to configure the tomcat account with the environment variables required to run Tomcat notably, the JAVA_HOMEand CATALINA_HOMEvariables. Restricting Account Privileges in Windows To ensure that unintentional privileges are not extended to the account, the tomcat account should be removed from all groups. When creating a user from the Users and Passwords control panel (called User Accounts in Windows Vista and Windows XP), Windows automatically adds tomcat to at least one group. The Computer Management utility must be used to remove the tomcat account from all groups. System administrators may want to consider creating a special Restricted Services group for the tomcat account (more on this strategy will follow in subsequent paragraphs). Note also that the tomcat account should be given a password that never expires, which can be accomplished with the same Computer Management utility. Restricting Account Privileges in Linux Create both a tomcatuser and a tomcat group. This is the default behavior of the useraddcommand. By assigning tomcat to its own new group, system administrators ensure that privileges are not unintentionally granted to the account. Running Tomcat with the Tomcat User After creating the tomcat account, the operating system must be configured to use the account when launching Tomcat. Configuring Windows If Tomcat is configured to run as a service (see Chapter 3 for details), you can use the Services utility to select a user account when launching Tomcat. The Services utility is in the Administrative Tools folder, which in turn is located in the Control Panel folder. To change the account, double-click on the Tomcat service and select the Log On tab. That tab provides the capability for the service to log on as a specific account. Enter the Tomcat account and its password in the appropriate locations. The service should then be restarted for the new setting to take effect. Configuring Linux There s no one way to configure a Linux system to start Tomcat with its own user account. The basic idea is to launch Tomcat using a syntax similar to the following in whatever startup scheme is used: /bin/su tomcat $CATALINA_HOME/bin/startup.sh

For high quality java hosting services please check java web hosting website.