Running Tomcat as Non-Root User

I don't believe there any issues with running Tomcat as root user. However, for the more security-conscious readers out there, here are some instructions on running Tomcat as a non-root user.

At this stage, the Tomcat packages, files and binaries are owned by root. We will first need to create a Tomcat user and group that will own these files, and under which Tomcat will run.

Tomcat User :: tomcat

Tomcat Group :: tomcat

Not too imaginative, huh ? We will now create the Tomcat user and group. Open a terminal window and, as root,

# groupadd tomcat
# useradd -g tomcat -d /opt/tomcat tomcat
# passwd tomcat

Notice that we specified the home directory of Tomcat to be /opt/tomcat. Some people believe that this is good practice because it eliminates an additional home directory that needs to be administered.

Now, we will put everything in /opt/tomcat under Tomcat user and group. As root,

# chown -R tomcat:tomcat /opt/tomcat

If /opt/tomcat is a symlink to your Tomcat install directory, you'll need to do this:

# chown -R tomcat:tomcat /opt/jakarta-tomcat-5.x.xx

Verify that JAVA_HOME and CATALINA_HOME environment variables are setup for tomcat user, and you should be good to go. Once the Tomcat binaries are under Tomcat user, the way you invoke it will be different.

To start Tomcat,

# su - tomcat -c /opt/tomcat/bin/startup.sh

To stop Tomcat,

# su - tomcat -c /opt/tomcat/bin/shutdown.sh

Also, be aware that your web applications will need to be deployed (i.e. copied to the web application directories) as user tomcat, instead of root. A little more hassle, but possibly a little safer too.

Note that, the JVM is a virtual machine with many threads under the same process. Therefore, because of OS constraints - all threads in the same process must run under the same user id. No thread may run as root unless they are all root. This is a limitation of the JVM.

Apache doesn't have this limitation since it uses multiple processes to do its work.

In Linux, a process can start as root, do some work then change its user id to something less via a OS system call. But once you switch down, you're stuck and can't go back.

MySQL Options

To start MySQL you simply specify mysql in a console window and press Return. The mysql programs are normally installed in the directory /usr/bin, so that it is unnecessary to provide the name of the directory.

When you start mysql you can use various options. To get a connection to the server you generally need two options, namely, -u name -p. The following list describes these and a few additional options and also gives some background information. These options are not only for mysql, but also for mysqladmin, mysqldump, and most other command tools.

-u name or —user=name: This option specifies which MySQL user name you wish to use. Depending on how MySQL is configured, there can be many MySQL users (see also Chapter 11). If no users have yet been set up or if you have administrative tasks to perform, use the user name root.

This user exists in every MySQL installation and is considered the system administrator.
If you omit the option -u, then under Unix/Linux the current login name will be used, while
under Windows, it will be ODBC. A login is possible only if users with these names have been
set up on the MySQL server.

The structure of an RPM package

The Red Hat Package Manager (RPM) is a tool that facilitates installing, uninstalling, and upgrading software for your Red Hat Linux system. It is a file that contains executable programs, scripts, documentation, and other files needed by an application or software unit. RPM packages are generally named using a convention that lets you determine the name of the package, the version of the software, the release number of the software, and the system architecture for which the application is intended. The following diagram shows how the components of a package name are arranged:

(1) Name

(2) Version

(3) Release

(4) Architecture

When you update a package, RPM installs the new version of the software but attempts to leave your existing configuration files intact. You can update a package by using the -U option of the rpm command:

rpm -Uvh  package 

When you update a package, RPM automatically uninstalls the old version of the package before installing the new one.

http://www.ibm.com/developerworks/linux/library/l-rpm2/index.html

Tomcat user

For security reasons, tomcat should run with low privileges. Create a tomcat user and set that user’s login shell to /sbin/nologin and locking the user’s password so that it can’t be guessed. Also, it’s probably a good idea to make the tomcat user’s primary group the nobody group or another group with similarly low permissions.

To create the tomcat user, you will need to do this as the root user:

# useradd -g 46 -s /sbin/nologin -d /opt/tomcat/temp tomcat

If you do not have root access, you could run Tomcat as your login user, but beware that any security vulnerabilities in Tomcat could be exploited remotely as your user account.

Tomcat user

For security reasons, you should probably create a tomcat user with low privileges and run Tomcat as that user. We suggest setting that user’s login shell to /sbin/ no login and locking the user’s password so that it can’t be guessed. Also, it’s probably
a good idea to make the tomcat user’s primary group the nobody group or another group with similarly low permissions. You will need to do this as the root user:

# useradd -g 46 -s /sbin/nologin -d /opt/tomcat/temp tomcat

If you do not have root access, you could run Tomcat as your login user, but beware that any security vulnerabilities (which are extremely rare) in Tomcat could be exploited remotely as your user account.

Relaying port 80 to port 8080

It is true that the JVM process must run as the root user in order to open a server socket on port 80 on non-Windows operating systems. But, the JVM would not need to run as root if something outside the JVM process could relay all port 80 TCP connections to Tomcat on some port higher than 1024 (such as port 8080, for example).

Tomcat can open its web server on port 8080, andsomething else with the proper permissions can relay port 80 TCP connections to Tomcat’s port 8080. This is often referredto as port relaying or net filtering and is such a handy and common feature that there are more ways than one to do this on any given operating system.

You can route all port 80 TCP connections to all network destinations that the machine is configured for by entering these two commands:

# iptables -t nat -I PREROUTING -p tcp --dport 80 -j REDIRECT --to-ports 8080

# iptables -t nat -I OUTPUT -p tcp --dport 80 -j REDIRECT --to-ports 8080

They will add the necessary relaying rules to your iptables configuration. This tells the kernel that all TCP connections destined for the machine on port 80 need to be redirected to port 8080.

Understanding the comcat-users.xml file

Tomcat's user database realm uses the tomcat-users.xml file by defaut and reads the entire file into memory.

Every Servlet 2.4 web application must contain a web.xml deployment descriptor. This file must be placed in the WEB-INF directory of the web application.

However, Tomcat comes with a default web.xml in CATALINA_HOME/conf. This file is similar to a web application's web.xml file but is used to specify the default properties for all web applications that are running within this server instance.

Cryptography

Basics of web cryptography:
(1) Symmetric:
- DES - fixed length key of 56 bits.
- 3DES - fixed length key of 168 bits (112 effective)
- Blowfish - variable length key up to 448 bits. Fast and free.
- IDEA - fixed length key of 128 bits. Fast, patented, and free for non-commercial use.
- RC4 - keys can be anywhere from 1 to 2,048 bits long (40 and 128-bit key lengths are commonly used.) RC4 is very fast and in widespread use.
- AES - keys can be 128, 192, or 256 bits long. Chosen to replace DES and 3DES.

(2) Asymmetric:
- RSA (Rivest, Shamir, Adleman) - public-key cryptography system.
- DSA (Digital Signature Algorithm) -
- Eliptic Curve - a mathematically different approach to public-key encryption.

(3) Hashing:
- MD5 - produces 128-bit output from input of any length. Released as RFC-1321.
- SHA-1 - produces 160-bit output from input of any length.
- SHA-256, SHA-384, and SHA-512.

(4) Certificates:
- Self-signed certificates - useful in some instances.
- Certificates signed by a private CA - used only for inernal purposes among a limited circle of users. This is similar to employee passes.
- Certificates signed by a public CA -

(5) SSL
- SSL3.1 is the same as TLS 1.0 is defined in RFC-2246
- SSL requires one exlcusive IP address per we site.
- RFC-2817 defines a way to upgrade from non-SSL to SSL communication.

A client MAY offer to switch to secured operation during any clear
 HTTP request when an unsecured response would be acceptable:

     GET http://example.bank.com/acct_stat.html?749394889300 HTTP/1.1
     Host: example.bank.com
     Upgrade: TLS/1.0
     Connection: Upgrade

 In this case, the server MAY respond to the clear HTTP operation
 normally, OR switch to secured operation (as detailed in the next
 section).

- SSL is a hybrid protocol. Every SSL connections consists of essentially two phases:
(a) Handshake phase - during this phase, the server sends the client its certificate and the client verifies the server's identity using public-key cryptography. In some cases, the server also requires the client to have a certificate, and client verification is also performed. After server verification is complete, the client and server agree on a common set of encryption protocols and generate a set of private cryptography secret keys.
(b) Data-exchange phase - with secret keys agreed on and known to both parties, the communication resumes using fast symmetric encryption protocols until both parties agree to close down the communication channel.
- OpenSSL:
$ openssl s_client -host www.thawte.com -port 443
- to generate a private key
$ openssl genrsa -out server.key 1024
- to extract the public key from the private key
$ openssl rsa -in server.key -pubout
- to generate a certificate signing request (CSR)
$ openssl req -new -key server.key -out server.csr
- to sign your own certificate
$ openssl x509 -req -days 35 -in server.csr -signkey server.key -out server.crt


ServerName www.apachesecurity.net
DirectoryRoot /var/www/empty
RedirectPermanent / https://www.apachesecurity.net/









Named-based Virtual Hosting

MySQL Security

Managing and Using MySQL - 2nd Edition:
- Database administrators manage access to the database engine itself. They provide access to individual databases for specific applications and developers. They also make sure that a poorly designed application cannot be used as a tunnel into the data of another application.
- System administrators manage the security of the OS and hardware on which MySQL runs. Their job is to ensure that only MySQL DBAs have access to the physical files used by MySQL on a given machine.
- Database architects design the access to thea pplications to which the DBAs have granted access. A DBA, for example, may have given a web site full privileges to its database, but it is up to the database architect to ensure that only valid application users are taking advantage of those privileges.

In a production environment, a user is likely to be an application. The DBA creates a user ID and password to support the application, and database security controls how that application is allowed to interact with MySQL. The application can then pass on its rights to individual users of the application by acting on their behalves to access MySQL.

It is critical to assign a password to the MySQL root user as soon as you install MySQL.

$ mysqladmin -u root password 'password'

Note that the above command only works when the MySQL root password has not been set.

If you have two web sites using the same MySQL installation to store their data, you might create tow separate users to represent those applications. You can use these two separate user IDs to protect each application from the other.

MySQL in a chrooted Environment

Running a server in a chrooted environment greatly enhances overall system security on a Linux system. It does this by setting up an isolated environment in which files outside of a given directory are no longer accessible. That way, even if a security flaw is found in the server and exploited, the potential for damage is limited to the files in that directory, which should only be the files for that particular application.