Security Information

VMware is committed to providing products and solutions that allow you to assess the security of your information, secure your information infrastructure, protect your sensitive information, and manage security information and events to assure effectiveness and regulatory compliance. As part of this commitment, the following VMware tc Server-specific security information is provided to help you secure your environment:

External Interfaces, Ports, and Services

A tc Runtime instance uses TCP/IP ports to receive incoming requests and send outgoing responses. Different protocols (such as HTTP/S, JMX, and AJP) listen on different ports. If you create a tc Runtime instance using all default values, then the default TCP/IP ports for the various protocols are as follows:

HTTP: 8080
HTTPS: 8443
JMX: 6969
AJP: 8009

You can change the TCP/IP listen ports for a particular tc Runtime instance by updating the INSTANCE-DIR/conf/catalina.properties file, where INSTANCE-DIR refers to the directory in which the tc Runtime instance is located, such as /opt/tc-server/5.0.x/instances/myserver.

The following snippet of catalina.properties shows how to change the HTTP, HTTPS, and JMX ports to 8181, 8553, and 7979, respectively:

...
nio.http.port=8181
nio.https.port=8553
base.jmx.port=7979

VMware tc Server does not have any external interfaces or services that need to be enabled or opened.

Resources That Must Be Protected

The following tc Server configuration files should be readable only by the dedicated tc Server user who runs the tc Runtime instance:

server.xml
context.xml
web.xml
catalina.properties
jmxremote.password
keystore-name.keystore (Instances configured with the NIO Connector)
cert-name.cer (Instances configured with the APR Connector)
key-name.key (Instances configured with the APR Connector)

These configuration files are specific to a tc Runtime instance and are stored in the INSTANCE-DIR/conf directory, where INSTANCE-DIR refers to the directory in which the tc Runtime instance is located, such as /opt/tc-server/5.0.x/instances/myserver.

Log File Locations

The default log files for a tc Runtime instance are as follows:

catalina.out: Contains System.out and System.err messages.
catalina.date.log: Contains log messages from the Catalina service.
localhost.date.log: Contains log messages from the localhost engine of the Catalina service.
localhost_access_log.date.txt: Contains information about access requests.

These log files are specific to a tc Runtime instance and are stored by default in the INSTANCE-DIR/logs directory, where INSTANCE-DIR refers to the directory in which the tc Runtime instance is located, such as /opt/tc-server/5.0.x/instances/myserver.

These log files should be readable and writable only by the dedicated tc Server user who runs the tc Runtime instance.

User Accounts Created at Installation

If you install VMware tc Server on Red Hat Enterprise Linux (RHEL) using the RPM, then a user with the following characteristics is automatically created:

ID: tcserver
Group: tcserver
You must log in as root or user with appropriate sudo privileges and su - tcserver.

When installing from RPM on RHEL, the tc Server installation directory will be owned by the root user, with group tcserver. The tcserver user will have permission to execute tcserver command. You should create tc Runtime instances as the tcserver user, and stop and start them as this user.

When installing tc Server on Windows or from a *.zip or *.tar file, a user account is not automatically created for you. Rather, you must create a dedicated tc Server user account whose only purpose is to run tc Runtime instances. Additionally:

This user should be the only user who has the permission to start and stop the tc Runtime instance, and should have no other permissions.
It should not be possible to logon to the computer directly as this dedicated tc Server user.
tc Server configuration files should be readable only by this dedicated tc Server user.
tc Server log files should be readable and writable only by this dedicated tc Server user.

Obtaining and Installing Security Updates

VMware tc Server is a Web application server based on open-source Apache Tomcat. A particular version of tc Server includes particular versions of re[ackaged Apache Tomcat, such as tomcat-9.0.6.B.RELEASE or tomcat-8.5.27.B.RELEASE. We refer to these Apache Tomcat packages as "tc Runtimes" which contain the base source code of their equivalent Apache Tomcat version plus tc Server enhancements and in some occasions additional bug and security fixes not available in the original Apache Tomcat release. New versions of tc Servers typically include updated versions of tc Runtimes, some of which might fix important security vulnerabilities.

See Obtaining tc Server for instructions on how to download tc Server which will contain updates to tc Runtime.

See Upgrade and Migration Guide for details.

File System Permissions

VMware tc Server file system permissions are basic however should be adjusted based on the security requirements of the application. In a single user development environment, the permissions provided in the downloaded archive are sufficient. In production environments the permissions may be tightened to meet the requirements of the application.

To create or modify an instance the user should be able to execute the tcserver command. This user also requires write access to the tcruntime instances directory. In addition read permission is required for templates, runtimes, and the contents of the downloaded archive.

To control an instance, the user should be able to execute the tcserver command and have read permissions to the lib and bin directory from the downloaded archive. In addition should have read permissions to the instance directory with write permissions to the logs directory of the instance. See above sections for additional permission requirements.

Instance Permissions

A tc Runtime instance can have tighter permissions if required. The following is an example of security permissions.

All files owned by root/Administrator
tcserver (or dedicated for this instance) group
- read for everything
- execute for scripts
- write for logs, temp
- It is possible for webapps and work to be read only, if the deployment and app do not require write permissions
none for everyone else