This article is taken from IBM China, developerWorks. http://www-900.ibm.com/developerWorks/cn/Linux/L-SECJAV/index.shtml
=========
Safety settings LINUX running Java service - Build a safe cage level for Tomcat: primary
Dennis M. Sosnoski (DMS@sosnoski.com) President, Sosnoski Software Solutions, Inc. 2003 July
Enterprise Java expert Dennis Sosnoski How does Java Server Technology Suitable for Linux to begin an explanation of his views on October 10, 2004, and then give a suggestion for setting a Tomcat Java Servlet engine on Linux.
The Linux platform and the Java platform have a long time, but there is often the relationship that often experiences the twists. To build a high-performance virtual machine, it is necessary to keep up with the growing core Java API collection, which makes the complexity that makes the development of the Java platform "clean room" to achieve early action difficulties. The Chartered implementation of Java technology is ultimately available for Linux, but these implementations are not open source. Therefore, most Linux distributions do not include this license implementation.
Despite these difficulties, Java platforms have also provided a lot of benefits, resulting in increasingly using this license on Linux, especially for server applications. In this article, I reviewed the advantages of the Java platform to the server application and then studied the issues involved in the Java service on Linux. As an actual example, I will discuss the details of the Tomcat Java Servlet engine that sets Apache Software Foundation for independent operations.
Why use the Java platform?
There are many reasons to explain why Java platforms become a widely accepted selection based on a server-based commercial application. I will focus mainly I think three reasons for this environment: cross-platform compatibility, managed runtime environment and easy development.
Java applications offer binary compatibility across multiple operating systems and hardware platforms. For non-GUI server applications, in particular, in such applications, very few tests are typically required in the actual target system. Developers can coding and debugging on any platform they like, while still deploying these applications into the environment they may not directly control.
The runtime feature of the Java Virtual Machine (JVM) environment enhances program security in several ways. One of the most significant aspects is strict type inspection, array boundary check and automatic garbage collection combination thoroughly prevents the most destructive form of server code attack: buffer overflow, repeatedly released errors and free pointers. The Java language is used in Applet. It has been evolving, and there is also a perfect system for fine granular access control for facilities that have confidently have security risks. These methods can be used for standalone applications, but they have constructed in the framework of many Java services.
These runtime program security features also provide convenience developed in Java language. It is difficult to make any precise measurements for convenience, but most developers who have turned to Java programming, such as C , have acknowledged that their productivity has increased after the transition. The part is because the type determination is strictly enforced at compile time and runtime, and the simplicity of automatic memory management. Another factor is a collection of standard API extensions developed for Java platforms. These APIs may be a major challenge for new developers, but once they learn, the API will provide excellent cross-platform support for a variety of business needs.
Of course, for some applications, the Java platform may be a bad choice. Although the JVM architecture continues to improve, Java applications typically run slightly slower than C or C applications using the same algorithm. According to my experience and test, I estimate that this speed difference is about 20% to 50% of most server applications running on a franchise JVM, but it is largely dependent on the quality of the code. Compared to the independent procedures, Java applications running on these JVMs have to endure slower, but this is usually not a major problem for long-running server applications. In most cases, reduced performance and slower starts are just minimal costs paid for the enhanced security of Java platforms and faster development advantages.
Open source alternative
In addition to standard license JVM (free use, source code is limited; available for Linux for Sun, IBM, BEA, and BlackDown), there are several other alternative seals for Linux. These options include "clean room" open source JVM implementation, where the most widely used may be Kaffe (which contains it in many Linux distributions). Kaffe is a very meaningful project that has completed some surprising work, but it can only provide limited compatibility with the current license JVM. Therefore, it is often not available for server applications for the enterprise types of this article.
Open source work for the native code compiler for the Java program has several alternatives. The most important project here is GNU Compiler Collection GCJ. The native code compiler, such as CGJ, converts the platform-independent Java byte code to a platform-specific code (this is performed in the JVM, which is typically run in the JVM. Convert bytecode to a platform-specific code).
This machine code compiles that it is very likely to be a slower method that avoids the slower Java application running in JVM. However, compilers using this method usually do not match the stable state performance of the contemporary firing JVM. This situation is particularly outstanding if the Java application uses the dynamic characteristics of the Java platform (such as using reflections to access fields or put into runtime selection.). Based on the implementation and compilation options used, this machine code compiles may also weaken many of the Java platforms. Finally, many Java APIs cannot be used with the compiled local code due to the license problem. Due to these restrictions, this machine code is currently not a good choice for the Java platform server application.
C # how?
An alternative method with many common time in the Java runtime environment is Microsoft's C # language and associated public language runtime (CLR). C # is a tight derivative of Java language, and the CLR may allow C # to use on many platforms. The CLR also provides many runtime security features of JVM (although there is a serious weakening export). Microsoft .NET implementation also supports the precompiled cost of codes to get faster start, which is the same as GCJ's job made by Java bytecode. Of course, Linux users cannot use this feature directly because .NET is only available for Windows systems.
Mono Project is working to build a "clean room" open source C # and equivalent to CLR for a variety of Linux products. Now, the C # compiler in the project has been developed, and most of the CLRs have been completed, and Microsoft has published it to standardize. However, there is still many work to do, regardless of the performance or functional point of view, there are many jobs to do before it has become a reasonable Java platform. The CLR contains only basic contents with the Java core class library equivalent. Before you can see it as a reasonable option for enterprise software development, you need to use many additional APIs to supplement it. Mono Project is committed to the development of other portions other than CLR, if these transplants are successful - and if Microsoft does not impose its patents in these parts of .NET - then they will help to meet C # to become server software on Linux The need for the development of reliable platform. But to make those assumptions become a reality, you need to do a lot of work, and the Java program's native code compiler and open source JVM provide more stable to those users who do want to avoid using licensed JVMs and can endure limited functionality. Alternative selection.
Apache Tomcat
One of the most commonly present Java platform server applications is Apache Tomcat. Tomcat is based on an open source project based on the source code donated by Sun. It is an HTTP server, which is developed by Java Community Process, a formal reference implementation of a widely used Servlet and JavaServer Page (JSP) technology. I will use Tomcat as a sample Java application in this article to deploy it into a service on Linux. If you want to try to run Tomcat, you will need to install the Java Development Kit, Java Development Kit, JDK, instead of installing a smaller Java ruironment, jre.
Servlet and JSP technology are used to construct an HTTP server application. Although many features (including access security, session management, and thread control) have been added, it itself is only roughly equivalent to the CGI interface customized to quickly and directly directly directly. JSP technology provides an easy way to process dynamically generated HTML pages, which are directly compiled into servlets for fast running.
In addition to these two technologies, Tomcat also provides many other features. With its own performance, it is actually a full-feature web server, but it usually uses the front-end of the Apache Web server on the Linux system. Apache provides many advanced performance to Tomcat to suit static content. The Apache front end is very useful for web applications with high ratio of static content and high usage. But for many simple web applications, it is not necessary to use it. When it is easier to configure and manage, you can run Tomcat alone to provide sufficient performance (at least for developers who have not previously used Apache).
One big problem with port puzzle running Tomcat is that it cannot access standard HTTP ports 80 unless run as root user. The idea of running a server application as a root user is usually not a problem discussed by the Shangliu Company, so I will completely give up this idea! Use ports other than 80 are a better option (for example, Tomcat default port 8080). This is usually suitable for testing, but when the user is accessing the service, it will result in a messy URL because the port number is required to clearly explain in the request. Using non-standard ports also means that you need to reconfigure all firewalls if you need an external access. XINETD Solution Fortunately, Linux supports some simple ways to process port 80 requesting port 80 using Tomcat (or any other user mode application). A common way is through xinetd. Xinetd is an Internet service daemon with a wide access control and logging support, which also has convenient redirection features. Redirection Lets you configure the system to accept the entry request on a port, and then pass the request to another port or even another IP address.
If you want to set Tomcat on your system to process port 80 requests, you need to add a xinetd configuration file to achieve this. Assume that XINETD is installed on the default path, you can perform this operation by adding a file (in root user identity) to the /etc/xinetd.d directory. Listing 1 provides a sample profile for Tomcat.
Listing 1. xinetd redirection configuration # Redirects any requests on port 80 # to port 8080 (where Tomcat is listening) service tomcat {socket_type = stream protocol = tcp user = root wait = no port = 80 redirect = localhost 8080 disable = no}
After adding the configuration file, you need to restart the xinetd to actually activate the redirection. In most Linux installations, restart xinetd by performing the following command as root user:
/ sbin / service xinetd Restart
As long as the configuration file is placed in the /etc/xinetd.d directory, the redirection will be automatically started when the system is restarted. If the Tomcat is not set to automatically start, the request will be refused before starting Tomcat.
IPTables solution xinetd is a good way to process the request redirection, but it runs a process to actually forward data between ports, which does have increased some overhead. The latest Linux kernel version supports a better setting redirection by using iptables. The difference between iptables and Xinetd is that it is a real kernel component. Therefore, it avoids the increase in the XINETD method. The only disadvantage that uses iptables is that it may be more difficult to configure than xinetd, and it can only be used for quite new kernel versions.
You need to run a 2.4.x or updated kernel that supports iptables so that I will use the technology described here. Configuring and setting iptables is a subject that is aware of several articles to separately describe, so I don't plan to discuss this theme here. If you need help to iptables, please read the Linux Distributed Handbook. To quickly check if iptables are running on your system, try to perform as root user: / sbin / service iptables status
If it is running, you will see a list of tables and chains on the console.
Iptables use several different tables and chains that follow the package processing rules. In order to redirect the HTTP request from the port 80 to another port in the system, you will use the NAT table (representing the network address translation, network address translation) and the preording chain. Listing 2 provides the actual command to be executed (identified in root user) to facilitate the addition of a rule that handles this request. The role of this rule is to modify the target port 80 of the entry package into the target port 8080, so this rule will only work correctly when you do not block the use of port 8080 from the outside. Once this command is executed, you should be able to process the request immediately.
Listing 2. iptables redirection rules / sbin / iptables -t nat / -a preording -j redirect -p tcp / --destination-port 80:80 --to-ports 8080
It will always be valid before you restart the system. If you want to make this redirect permanently, you need to do the following command:
/ sbin / service iptables save
To save the current iptables configuration.
Automatic starting Tomcat When another issue of Java services such as Tomcat is to start the application when the system starts, and how to automatically stop it when the system is turned off (in other words, use it as a daemon run). Experienced Linux users already know how to do it, but if you are still a Linux newbie, the following is some basic knowledge.
If you are running it on your personal system and want to use the files and directories of Tomcat directly like Tomcat, you can use your own username to set it. However, usually, a better idea is: Set a separate user for any program that will run as a daemon. To do this for Tomcat, execute as root user:
/ usr / sbin / usradd Tomcat
This will create a user account called Tomcat and create a primary directory / home / Tomcat for Tomcat installation. The owner of the main directory created is Tomcat users, and usually only allows users to access (of course, there is also root users). If you want to access Tomcat installations from other accounts, you can change your license to include group access and add Tomcat groups to these other accounts.
In short, to run Tomcat as a daemon, you need to add the service profile to the /etc/init.d directory, and you may have to name the file "Tomcat". Listing 3 provides samples of the file. This assumes that Tomcat is installed under / home / tomcat and there are two shell script files in this location for processing launch and stop servers (TCStart.sh and TCStop.sh). You need to use these files to set the environment variables required for Tomcat (including Java_Home and JDK_Home) before performing the actual Tomcat startup or stopping the script. Listing 3. Tomcat service definition #! / Bin / bash ## Tomcat Starts Tomcat Java Server. ### chkconfig: 345 88 12 # description: Tomcat is The Server for Java Servlet Applications. ### Begin Init Info # provides: $ Tomcat ### End Init Info
# Source Function Library .. /etc/init.d/functions
[-f /home/tomcat/tcstart.sh] || exit 0 [-f /Home/tomcat/tcstop.sh] || exit 0
Retval = 0
Umask 077
Start () {echo -n $ "Starting Tomcat Java Server:" Daemon Su -c /Home/tomcat/tcstart.sh Tomcat Echo Return $ RETVAL} Stop () {echo -n $ "Shutting Down Tomcat Java Server:" Daemon Su -c /Home/tomcat/tcstop.sh Tomcat Echo Return $ RETVAL} Restart () {stop start} case "$ 1" in start) start ;; stop) stop ;; restart | reload) restart ;; *) Echo $ "USAGE: $ 0 {start | stop | restart}" EXIT 1ESAC
EXIT $?
The following is a sample TCStart.sh, which can modify it to fit your installation.
Listing 4. Sample TCSTART.SH
#! / bin / Bashexport JDK_HOME = / usr / java / jdkexport java_home = / usr / java / jdk # run the startup script from tomcat installation / home / tomcat / server / bin / startup.sh
Chroot: The biggest security prischers may further discuss the protection of Java language services in real paranoia. This is especially useful when the service provides some form of access to the local file system. JVM runtime security features do not prevent files that have access to file systems from accessing files other than user-specific files. In the case of Tomcat, file access is inherent to use as an HTTP server. It usually limits those files for each web application to limit those files in the application directory, but the servlet application can avoid these restrictions. This happens when Tomcat runs together with the front-end web server such as Apache. By using Chroot, you can block anything other than the space left by Tomcat (and all WEB applications running under Tomcat). Chroot does not specific to Java applications in any way, but it is a simple way to add the final wrapper for JVM. I will introduce it to the point of your point for those who are not familiar with Chroot concept.
Chroot is made similar to the JVM sandbox for performing Java code, but it applies to the file system itself. Chroot executes a command and sets the location you specified into a valid root directory. The command (can be a shell script that performs other commands, including applications), can only access part of the file system in the specified active root directory. The rest of the file system does not exist at this command.
To use Chroot for applications such as Tomcat, you need to copy some basic system applications and libraries (including actual Java JDK installation) to new virtual root directory. This may take up a number of spaces - maybe from one hundred megabytes to one thousand megabytes or more - depending on how much effort you want to reduce these applications and libraries to minimize. To set it the simplest method, the most wasteful space: Just copy the entire / bin, / lib, / usr / bin, and / usr / lib directory tree, and Java installation to the new root directory, so that root users become all files The owner and the only authorized writer. If you want to keep disk usage to minimize, you can selectively copy the commands you need in Chroot (including basic commands, RM, Echo, Echo, Echo, Echo, and Cat, and actual Java installation) and those commands used by them ( You can find those libraries by using LDD).
Next, you will need to create some additional directories as a reduced version of the regular system. This includes / dev, and device / dev / null and / dev / zero; / etc and / etc / passwd and / etc / group files (only Root and Tomcat items only), perhaps host. If you are running on a multiprocessor system, you also need to hool / PROC systems in the new root directory because JVM uses the system to coordinate each processor.
Finally, in order to run as a user Tomcat after setting Chroot, you may need to build a Su command version that can run in a virtual root directory (many distribution general versions are not allowed to do this). To do this, you can get the SH-Utils source code from the GNU project and directly build the SU directly, then copy it to the new root directory / bin directory.
Once all these settings have been completed, you can try to perform as root user (assuming the new root directory is / home / tomcat):
/ usr / sbin / chroot / home / tomcat / bin / su Tomcat
If the settings are correct, this should let you run as Tomcat in the new root, and you can try to start and stop Tomcat using your script. After confirming all things, the last step is to change the Tomcat service definition in Listing 3 into the use of Chroot instead of SU, move the su command to the TCStart.sh script and tcstop.sh scripts. It is also necessary to ensure that these scripts can only be modified by root users. I hope this outline is clear, this process is not suitable for daring people! If you choose to take this route using Chroot, but I haven't used Chroot before, then you must refer to one of the online chroot reference materials to get details. But this does give your Java server code best to isolate, and in some cases, the inner tranquility brings to do so.
Conclusion Linux and Java technology are winning the market share of commercial systems. Although there is a principle difference between open source Linux and a license Java technology, both of these are indeed well. Linux is an excellent deployment environment for Java applications, especially for server types, and Java technology is established as an advanced approach to enterprise software development and has been recognized.
Through correct precautions, Java server applications running on Linux can provide very high security - even higher than native applications - because Java technology eliminates common sources of many weaknesses in server applications. The cross-platform nature of Java technology is a huge resource collection including business developers and Linux immediately ready applications. Java server applications start play an important role in the growing Linux server market share, and this trend will only help these two technologies in the future.
I would like to thank Miles Sabin to point out the / proc file system to solve the problem of Chroot Java on the multiprocessor system.
Reference
Please find the details of the Apache Tomcat Java Language Web Server item for Apache Software Foundation. Please check the author's latest open source Java technology project: JIBX XML data binding framework. IBM HTTP Server for iSeries includes a servlet and JSP engine based on Tomcat. Please read more about Tomcat's developerWorks article: "Tomcat's filtering" "Taming your Tomcat: Filtering tricks for tomcat 5"
