<commit_before><?xml version="1.0" encoding="UTF-8"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<!DOCTYPE document [
  <!ENTITY project SYSTEM "project.xml">
]>
<document url="security-howto.html">

    &project;

  <properties>
    <title>Security Considerations</title>
  </properties>

<body>

<section name="Table of Contents">
<toc/>
</section>

  <section name="Introduction">
    <p>Tomcat is configured to be reasonably secure for most use cases by
    default. Some environments may require more, or less, secure configurations.
    This page is to provide a single point of reference for configuration
    options that may impact security and to offer some commentary on the
    expected impact of changing those options. The intention is to provide a
    list of configuration options that should be considered when assessing the
    security of a Tomcat installation.</p>

    <p><strong>Note</strong>: Reading this page is not a substitute for reading
    and understanding the detailed configuration documentation. Fuller
    descriptions of these attributes may be found in the relevant documentation
    pages.</p>
  </section>

  <section name="Non-Tomcat settings">
    <p>Tomcat configuration should not be the only line of defense. The other
    components in the system (operating system, network, database, etc.) should
    also be secured.</p>
    <p>Tomcat should not be run under the root user. Create a dedicated user for
    the Tomcat process and provide that user with the minimum necessary
    permissions for the operating system. For example, it should not be possible
    to log on remotely using the Tomcat user.</p>
    <p>File permissions should also be suitably restricted. In the
    <code>.tar.gz</code> distribution, files and directories are not world
    readable and the group does not have write access. On Unix like operating
    systems, Tomcat runs with a default umask of <code>0027</code> to maintain
    these permissions for files created while Tomcat is running (e.g. log files,
    expanded WARs, etc.).</p>
    <p>Taking the Tomcat instances at the ASF as an example (where
    auto-deployment is disabled and web applications are deployed as exploded
    directories), the standard configuration is to have all Tomcat files owned
    by root with group Tomcat and whilst owner has read/write privileges, group
    only has read and world has no permissions. The exceptions are the logs,
    temp and work directory that are owned by the Tomcat user rather than root.
    This means that even if an attacker compromises the Tomcat process, they
    can&apos;t change the Tomcat configuration, deploy new web applications or
    modify existing web applications. The Tomcat process runs with a umask of
    007 to maintain these permissions.</p>
    <p>At the network level, consider using a firewall to limit both incoming
    and outgoing connections to only those connections you  expect to be
    present.</p>
  </section>

  <section name="Default web applications">

    <subsection name="General">
      <p>Tomcat ships with a number of web applications that are enabled by
      default. Vulnerabilities have been discovered in these applications in the
      past. Applications that are not required should be removed so the system
      will not be at risk if another vulnerability is discovered.</p>
    </subsection>

    <subsection name="ROOT">
      <p>The ROOT web application presents a very low security risk but it does
      include the version of Tomcat that is being used. The ROOT web application
      should normally be removed from a publicly accessible Tomcat instance, not
      for security reasons, but so that a more appropriate default page is shown
      to users.</p>
    </subsection>

    <subsection name="Documentation"><commit_msg>Expand a little on JMX in the security considerations page<commit_after><?xml version="1.0" encoding="UTF-8"?>
<!--
  Licensed to the Apache Software Foundation (ASF) under one or more
  contributor license agreements.  See the NOTICE file distributed with
  this work for additional information regarding copyright ownership.
  The ASF licenses this file to You under the Apache License, Version 2.0
  (the "License"); you may not use this file except in compliance with
  the License.  You may obtain a copy of the License at

      http://www.apache.org/licenses/LICENSE-2.0

  Unless required by applicable law or agreed to in writing, software
  distributed under the License is distributed on an "AS IS" BASIS,
  WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
  See the License for the specific language governing permissions and
  limitations under the License.
-->
<!DOCTYPE document [
  <!ENTITY project SYSTEM "project.xml">
]>
<document url="security-howto.html">

    &project;

  <properties>
    <title>Security Considerations</title>
  </properties>

<body>

<section name="Table of Contents">
<toc/>
</section>

  <section name="Introduction">
    <p>Tomcat is configured to be reasonably secure for most use cases by
    default. Some environments may require more, or less, secure configurations.
    This page is to provide a single point of reference for configuration
    options that may impact security and to offer some commentary on the
    expected impact of changing those options. The intention is to provide a
    list of configuration options that should be considered when assessing the
    security of a Tomcat installation.</p>

    <p><strong>Note</strong>: Reading this page is not a substitute for reading
    and understanding the detailed configuration documentation. Fuller
    descriptions of these attributes may be found in the relevant documentation
    pages.</p>
  </section>

  <section name="Non-Tomcat settings">
    <p>Tomcat configuration should not be the only line of defense. The other
    components in the system (operating system, network, database, etc.) should
    also be secured.</p>
    <p>Tomcat should not be run under the root user. Create a dedicated user for
    the Tomcat process and provide that user with the minimum necessary
    permissions for the operating system. For example, it should not be possible
    to log on remotely using the Tomcat user.</p>
    <p>File permissions should also be suitably restricted. In the
    <code>.tar.gz</code> distribution, files and directories are not world
    readable and the group does not have write access. On Unix like operating
    systems, Tomcat runs with a default umask of <code>0027</code> to maintain
    these permissions for files created while Tomcat is running (e.g. log files,
    expanded WARs, etc.).</p>
    <p>Taking the Tomcat instances at the ASF as an example (where
    auto-deployment is disabled and web applications are deployed as exploded
    directories), the standard configuration is to have all Tomcat files owned
    by root with group Tomcat and whilst owner has read/write privileges, group
    only has read and world has no permissions. The exceptions are the logs,
    temp and work directory that are owned by the Tomcat user rather than root.
    This means that even if an attacker compromises the Tomcat process, they
    can&apos;t change the Tomcat configuration, deploy new web applications or
    modify existing web applications. The Tomcat process runs with a umask of
    007 to maintain these permissions.</p>
    <p>At the network level, consider using a firewall to limit both incoming
    and outgoing connections to only those connections you  expect to be
    present.</p>

    <subsection name="JMX">
      <p>The security of the JMX connection is dependent on the implementation
      provided by the JRE and therefore falls outside the control of Tomact.</p>

      <p>Typically, access control is very limited (either read-only to
      everything or read-write to everything). Tomcat exposes a large amount
      of internal information and control via JMX to aid debugging, monitoring
      and management. Give the limited access control available, JMX access
      should be treated as equivalent to local root/admin access and restricted
      accordingly.</p>

      <p>The JMX access control provided by most (all?) JRE vendors does not
      log failed authentication attempts, nor does it provide an account
      lock-out feature after repeated failed authentications. This makes a
      brute force attack easy to mount and difficult to detect.</p>

      <p>Given all of the above, care should be taken to ensure that, if used,
      the JMX interface is appropriately secured. Options you may wish to
      consider to secure the JMX interface include:</p>

      <ul>
        <li>configuring a strong password for all JMX users;</li>
        <li>binding the JMX listener only to an internal network;</li>
        <li>limiting network access to the JMX port to trusted clients; and</li>
        <li>providing an application specific health page for use by external
            monitoring systems.</li>
      </ul>
    </subsection>

  </section>

  <section name="Default web applications">

    <subsection name="General">
      <p>Tomcat ships with a number of web applications that are enabled by
      default. Vulnerabilities have been discovered in these applications in the
      past. Applications that are not required should be removed so the system
      will not be at risk if another vulnerability is discovered.</p>
    </subsection>

    <subsection name="ROOT">
      <p>The ROOT web application presents a very low security risk but it does
      include the version of Tomcat that is being used. The ROOT web application
      should normally be removed from a publicly accessible Tomcat instance, not
      for security reasons, but so that a more appropriate default page is shown
      to users.</p>
    </subsection>

    <subsection name="Documentation">
{'fraction_non_alphanumeric': 0.05544090056285178, 'fraction_numerical': 0.002626641651031895, 'mean_word_length': 3.5385270327799065, 'pattern_counts': {'":': 0, '<': 117, '<?xml version=': 2, '>': 117, 'https://': 0, 'lorem ipsum': 0, 'www.': 2, 'xml': 4}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '645658', 'n_tokens_mistral': 2564, 'n_tokens_neox': 2498, 'n_words': 1427}