Security settings for Linux running Java services -- build a safe cage for Tomcat

Article title: Linux running Java services in security settings -- build a safe cage for Tomcat. Linux is a technology channel of the IT lab in China. Includes basic categories such as desktop applications, Linux system management, kernel research, embedded systems, and open source.
The Linux and Java platforms have a long history but often experience twists and turns. While building high-performance virtual machines, we must keep up with the increasing collection of core Java APIs, the complexity brought about by this greatly makes it difficult to develop the open source code "clean room" of the Java platform to implement early actions. Java Technology's licensed implementations can eventually be used in Linux, but these implementations are not open source code. Therefore, most Linux distributions do not include this license.
　　
Despite these difficulties, the Java platform provides many benefits, resulting in more and more use of the licensed implementation on Linux, especially for server applications. In this article, I reviewed the advantages of the Java platform for server applications, and then studied the problems involved in simple and secure deployment of Java services on Linux. As an example, I will discuss how to set detailed information about the widely used Tomcat Java servlet engine of the Apache Software Foundation for independent operations.
　　
Why Java platform?
There are many reasons to explain why the Java platform has become a widely accepted choice for server-based commercial applications. I will mainly discuss three reasons that I think are critical to this environment: cross-platform compatibility, managed runtime environment and ease of development.
　　
Java applications provide binary compatibility across multiple operating systems and hardware platforms. Especially for non-GUI server applications, in such applications, a very small number of tests are usually required in the actual target system. Developers can perform coding and debugging on any platform they like, and still deploy these applications in environments that they may not directly control.
　　
The runtime features of Java Virtual Machine (JVM) environments enhance program security in several ways. One of the most notable aspects is that the combination of strict type checks, array boundary checks, and automatic garbage collection completely prevents the most destructive form of server code attacks: buffer overflow, repeated release errors, and free pointers. The Java language was used for applet in the early days. after the development, the language also has a complete system for fine-grained access control of facilities that are already certain to have security risks. These methods are available for independent applications, but they have been built into many Java service frameworks.
　　
These runtime program security features also provide convenience for Java development. It is difficult to make any precise measurement of problems such as convenience, however, most developers who have a background in languages such as C and C ++ who have switched to Java programming admit that their productivity has increased since the change. This is partly because the type is strictly determined during compilation and runtime, and the simplicity of automatic memory management. Another factor is the set of standard API extensions developed for the Java platform. These APIs may be a major challenge for new developers, but once learned, they will provide excellent cross-platform support for various enterprise needs.
　　
Of course, for some applications, the Java platform may be a bad choice. Although the JVM architecture is continuously improved, Java applications generally run slightly slower than C or C ++ applications using the same algorithm. Based on my experience and tests, I estimate that the speed difference is within the range of 20% to 50% for most server applications running on a licensed JVM, however, this depends largely on the quality of the code. Compared with stand-alone programs, Java applications running on these JVMs still endure slow startup, but this is not a major problem for long-running server applications. In most cases, the performance reduction and slow startup are only a small cost for obtaining enhanced security and faster development advantages of the Java platform.
　　
Alternative open source code
In addition to standard licensed JVM (free of charge, but restricted source code; available for Linux in the Sun, IBM, BEA, and Blackdown organizations), there are several other alternatives to Linux. These options include the open source JVM implementation of the "clean room". The most widely used is Kaffe (which is included in many Linux distributions ). Kaffe is a very meaningful project and it has done some surprising work, but it can only provide limited compatibility with the currently licensed JVM. Therefore, it is generally not applicable to enterprise-type server applications.
　　
There are also several alternative options for the open source code of the local code Compiler for Java programs. The most important project here is the GCJ of the GNU Compiler set (GNU Compiler Collection. Using a native code compiler such as CGJ converts platform-specific Java bytecode before execution (this is compared with running in JVM, in JVM, the code is usually converted into platform-specific code at runtime ).
　　
The local code compilation shows that it is very likely to become a method to avoid slow startup of Java applications running in JVM. However, compilers that use this method usually cannot match the stable state performance of the contemporary chartered JVM. This situation is particularly prominent if Java applications use dynamic features of the Java platform (such as using reflection to access fields or load the classes selected at runtime. Depending on the implementation and compilation options used, local code compilation may also weaken many runtime security features of the Java platform. Finally, due to license issues, many Java APIs cannot be used with compiled local code. Due to these restrictions, the local code compilation is not a good choice for Java platform server applications.
　　
C # How?
One alternative to the Java Runtime Environment is Microsoft's C # Language and the related Common Language Runtime (CLR ). C # is a closely related derivative of the Java language. CLR may allow C # to be used on many platforms. CLR also provides many runtime security features of the JVM (although the exit is severely compromised ). The Microsoft. Net implementation also supports precompiled native code options for faster startup, which is the same as GCJ's work on Java bytecode. Of course, Linux users cannot directly use this function, because. Net is only applicable to Windows systems.
　　
Mono Project is committed to building open source code C # for a variety of Linux products and is equivalent to CLR products. Now, the C # compiler in this project has been developed and most of the CLR has been completed. Microsoft has released it for standardization. However, from the perspective of performance and functionality, there is still much work to be done before it becomes a proper alternative to the Java platform. CLR only contains the basic content equivalent to the Java core class library. Before we can regard it as a reasonable option for enterprise software development, we need to use many additional APIs to supplement it.
　　
The Mono Project is dedicated to developing projects other than CLR.. Net, if the transplantation is successful-and if Microsoft is incorrect. these parts of Net impose its patent rights-then they will help meet the needs of C # to become a reliable platform for Linux server software development. However, to make those assumptions a reality, you still need to do a lot of work. at the same time, the Java program's native code compiler and open-source JVM provide stable alternatives to users who really want to avoid having to use a licensed JVM and can tolerate limited functionality.
　　
Apache Tomcat
Apache Tomcat is one of the most common Java platform server applications. Tomcat is an open source project based on the source code originally donated by Sun. It is an HTTP server and is a formal reference implementation developed by Sun through Java Community Process for the widely used servlet and JavaServer Page (JSP) technology. I will use Tomcat as a sample Java application in this article and deploy it as a service on Linux. If you want to run Tomcat by yourself, you need to install the Java Development Kit (JDK) on the system, instead of installing a smaller Java Runtime Environment (Java Runtime Environment, JRE ).
　　
Servlet and JSP technologies are used to construct HTTP server applications. Although servlet technology has added many features (including access security, session management, and thread control ), however, it is just roughly equivalent to the CGI interface customized for fast and direct Java language calls. JSP provides a simple way to process dynamically generated HTML pages. these HTML pages are directly compiled into servlets for quick operation.
　　
In addition to these two technologies, Tomcat also provides many other features. Based on its own performance, it is actually a full-featured Web server, but it is usually used together with the Apache Web server front-end on Linux systems. Apache provides Tomcat with a lot of advanced performance for static content. Apache front-end is very useful for Web applications with a high proportion of static content and high usage. However, many simple Web applications do not need to be used. when it is easier to configure and manage, running Tomcat independently can provide sufficient performance (at least for developers who have never used Apache before ).
　　
Port problems
One major problem with running Tomcat separately is that it cannot access standard HTTP port 80 unless it is run as a root user. The idea of running server applications as root users is not generally discussed by upper companies, so I will give up this idea completely! Using ports other than 80 is a better choice (for example, Tomcat default port 8080 ). This is usually applicable to testing, but when a user is accessing the service, it will lead to messy URLs, because the port number needs to be clearly stated in the request. Using a non-standard port also means that if you need external access, you need to reconfigure all the firewalls.
　　
Xinetd solution
Fortunately, Linux supports some simple methods to process Port 80 requests using Tomcat (or any other user-based application. A common method is xinetd. Xinetd is an Internet service daemon with extensive access control and logging support. it also has convenient redirection features. Redirection allows you to configure the system to accept incoming requests from one port, and then pass the requests to another port or even another IP address for processing.
　　
If you want to set Tomcat on the system to process Port 80 requests, you need to add the xinetd configuration file to achieve this purpose. If xinetd is installed on the default path as usual, you can add a file (as root user) to the/etc/xinetd. d directory to perform this operation. Listing 1 provides a sample configuration file 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
Redirectly = localhost 8080