Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
Mark and Rémy, On 3/13/24 10:53, Mark Thomas wrote: On 13/03/2024 14:38, Rémy Maucherat wrote: wrote: 1. A longer default nag-duration That's a good start. If it is meant to be enabled by default, I would like a value that is long enough so that it is almost certain there's an issue. 2 years ? Rémy 2. Add an explicit "disable" (e.g. -1) I was thinking yes to this and setting it to -1 by default. 3. Disable the feature by default 4. Remove this feature entirely The target for this was really 8.5 which will immediately go out-of-support once 8.5.100 is released. So really the default for 8.5.100 should be "nag immediately", but we can't expect that anybody really uses the out-of-the-box server.xml without any customizations, so specifically setting the duration to some small number of days in server.xml isn't going to have any effect. The more I think about this the more I wonder if some further tweaks are required. This check only runs at startup. There are some (very) long running Tomcat instances out there. Is on startup enough? Should this check be periodic? If yes, how periodic? Once a day? Probably whatever frequency we went for with the TLS reload warnings would be about right. I'm going to make these changes immediately: 1. Implement -1 = disabled 2. Set default to -1 instead of 180 for main/10.1/9 3. Set default to 180 for 8.5.x It would be "easy" to configure this for periodic checking, but I'm not going to do that quite yet. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
On 13/03/2024 14:38, Rémy Maucherat wrote: wrote: 1. A longer default nag-duration That's a good start. If it is meant to be enabled by default, I would like a value that is long enough so that it is almost certain there's an issue. 2 years ? Rémy 2. Add an explicit "disable" (e.g. -1) I was thinking yes to this and setting it to -1 by default. 3. Disable the feature by default 4. Remove this feature entirely The target for this was really 8.5 which will immediately go out-of-support once 8.5.100 is released. So really the default for 8.5.100 should be "nag immediately", but we can't expect that anybody really uses the out-of-the-box server.xml without any customizations, so specifically setting the duration to some small number of days in server.xml isn't going to have any effect. The more I think about this the more I wonder if some further tweaks are required. This check only runs at startup. There are some (very) long running Tomcat instances out there. Is on startup enough? Should this check be periodic? If yes, how periodic? Once a day? Probably whatever frequency we went for with the TLS reload warnings would be about right. Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
n Wed, Mar 13, 2024 at 2:55 PM Christopher Schultz wrote: > > Rémy, > > On 3/12/24 12:05, Rémy Maucherat wrote: > > On Tue, Mar 12, 2024 at 3:02 PM Christopher Schultz > > wrote: > >> > >> Mark, > >> > >> On 3/12/24 05:00, Mark Thomas wrote: > >>> On 11/03/2024 21:38, schu...@apache.org wrote: > This is an automated email from the ASF dual-hosted git repository. > > schultz pushed a commit to branch main > in repository https://gitbox.apache.org/repos/asf/tomcat.git > > commit 3ab883aa746a5c577efa39d9080858e53ca77da6 > Author: Christopher Schultz > AuthorDate: Mon Mar 11 17:38:01 2024 -0400 > > Add checking for the age of the Tomcat version running and warn > if it's getting old. > >>> > >>> How do I disable this check if I don't want to use it? I'd expect > >>> something like set it to "-1". > >> > >> I could add a special case for "disable" or you could set it to a very > >> high value. > >> > >> If your Tomcat installation is still running in 32768 days, you > >> certainly won't give a damn if it starts issuing warnings. > > > > I don't like this either. It might get me into real trouble with my > > downstream, actually. > > > > Unless there's a security issue, I think people don't really really > > have to upgrade working production systems that often. For example, > > between 9.0.62 and 9.0.71, no CVEs above low. And even if there was > > most often a user will not be affected. Upgrading costs testing and > > resources, so ... > > > > I'm not advocating that users should never upgrade, but building in a > > nag by default is not great. Esp 6 months. By the time things are > > upgraded they will start nagging again the next day pretty much. Then > > a warn log about security often cannot be simply ignored. > > Okay. Are you suggestion any of the following? > > 1. A longer default nag-duration That's a good start. If it is meant to be enabled by default, I would like a value that is long enough so that it is almost certain there's an issue. 2 years ? Rémy > 2. Add an explicit "disable" (e.g. -1) > > 3. Disable the feature by default > > 4. Remove this feature entirely > > The target for this was really 8.5 which will immediately go > out-of-support once 8.5.100 is released. So really the default for > 8.5.100 should be "nag immediately", but we can't expect that anybody > really uses the out-of-the-box server.xml without any customizations, so > specifically setting the duration to some small number of days in > server.xml isn't going to have any effect. > > That's why I made it "on by default". > > Another option would be: > > 5. Change the behavior between 8.5 and the other branches. 8.5 could > have this on-by-default while the others do not. We might make it a > policy to "change to on-by-default around EOL time" so that most people > will not change the configuration from the default, but then the default > changes for the final release(s) in a branch. > > In terms of "you only need to upgrade if there are CVEs"... that would > be a very difficult policy for us to manage, because any release we know > has any CVEs would be released before we knew it had them. Any new > release with fixes cannot announce to the old releases that they need to > be upgraded. > > My goal was to improve security for those who are unlikely to be paying > attention to announce@tomcat or using any of the publicly (and > non-publicly) available bug trackers and services to ensure they aren't > running vulnerable versions of Tomcat. > > We often release fixes without announcing them until long after the > fact, which means that any new release could conceivably be a "security > release". You (downstream) won't know until later whether or not you > should have upgraded. So the best advice is to upgrade as often as it is > convenient for you to do so. This is simply a reminder to do it. > > Since we have releases roughly every month, I figured that > every-6-months would be a good cadence. And it can always be configured > to shut up "forever" if necessary. > > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
Rémy, On 3/12/24 12:05, Rémy Maucherat wrote: On Tue, Mar 12, 2024 at 3:02 PM Christopher Schultz wrote: Mark, On 3/12/24 05:00, Mark Thomas wrote: On 11/03/2024 21:38, schu...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 3ab883aa746a5c577efa39d9080858e53ca77da6 Author: Christopher Schultz AuthorDate: Mon Mar 11 17:38:01 2024 -0400 Add checking for the age of the Tomcat version running and warn if it's getting old. How do I disable this check if I don't want to use it? I'd expect something like set it to "-1". I could add a special case for "disable" or you could set it to a very high value. If your Tomcat installation is still running in 32768 days, you certainly won't give a damn if it starts issuing warnings. I don't like this either. It might get me into real trouble with my downstream, actually. Unless there's a security issue, I think people don't really really have to upgrade working production systems that often. For example, between 9.0.62 and 9.0.71, no CVEs above low. And even if there was most often a user will not be affected. Upgrading costs testing and resources, so ... I'm not advocating that users should never upgrade, but building in a nag by default is not great. Esp 6 months. By the time things are upgraded they will start nagging again the next day pretty much. Then a warn log about security often cannot be simply ignored. Okay. Are you suggestion any of the following? 1. A longer default nag-duration 2. Add an explicit "disable" (e.g. -1) 3. Disable the feature by default 4. Remove this feature entirely The target for this was really 8.5 which will immediately go out-of-support once 8.5.100 is released. So really the default for 8.5.100 should be "nag immediately", but we can't expect that anybody really uses the out-of-the-box server.xml without any customizations, so specifically setting the duration to some small number of days in server.xml isn't going to have any effect. That's why I made it "on by default". Another option would be: 5. Change the behavior between 8.5 and the other branches. 8.5 could have this on-by-default while the others do not. We might make it a policy to "change to on-by-default around EOL time" so that most people will not change the configuration from the default, but then the default changes for the final release(s) in a branch. In terms of "you only need to upgrade if there are CVEs"... that would be a very difficult policy for us to manage, because any release we know has any CVEs would be released before we knew it had them. Any new release with fixes cannot announce to the old releases that they need to be upgraded. My goal was to improve security for those who are unlikely to be paying attention to announce@tomcat or using any of the publicly (and non-publicly) available bug trackers and services to ensure they aren't running vulnerable versions of Tomcat. We often release fixes without announcing them until long after the fact, which means that any new release could conceivably be a "security release". You (downstream) won't know until later whether or not you should have upgraded. So the best advice is to upgrade as often as it is convenient for you to do so. This is simply a reminder to do it. Since we have releases roughly every month, I figured that every-6-months would be a good cadence. And it can always be configured to shut up "forever" if necessary. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
On Tue, Mar 12, 2024 at 3:02 PM Christopher Schultz wrote: > > Mark, > > On 3/12/24 05:00, Mark Thomas wrote: > > On 11/03/2024 21:38, schu...@apache.org wrote: > >> This is an automated email from the ASF dual-hosted git repository. > >> > >> schultz pushed a commit to branch main > >> in repository https://gitbox.apache.org/repos/asf/tomcat.git > >> > >> commit 3ab883aa746a5c577efa39d9080858e53ca77da6 > >> Author: Christopher Schultz > >> AuthorDate: Mon Mar 11 17:38:01 2024 -0400 > >> > >> Add checking for the age of the Tomcat version running and warn > >> if it's getting old. > > > > How do I disable this check if I don't want to use it? I'd expect > > something like set it to "-1". > > I could add a special case for "disable" or you could set it to a very > high value. > > If your Tomcat installation is still running in 32768 days, you > certainly won't give a damn if it starts issuing warnings. I don't like this either. It might get me into real trouble with my downstream, actually. Unless there's a security issue, I think people don't really really have to upgrade working production systems that often. For example, between 9.0.62 and 9.0.71, no CVEs above low. And even if there was most often a user will not be affected. Upgrading costs testing and resources, so ... I'm not advocating that users should never upgrade, but building in a nag by default is not great. Esp 6 months. By the time things are upgraded they will start nagging again the next day pretty much. Then a warn log about security often cannot be simply ignored. Rémy > -chris > > - > To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org > For additional commands, e-mail: dev-h...@tomcat.apache.org > - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
Mark, On 3/12/24 05:00, Mark Thomas wrote: On 11/03/2024 21:38, schu...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 3ab883aa746a5c577efa39d9080858e53ca77da6 Author: Christopher Schultz AuthorDate: Mon Mar 11 17:38:01 2024 -0400 Add checking for the age of the Tomcat version running and warn if it's getting old. How do I disable this check if I don't want to use it? I'd expect something like set it to "-1". I could add a special case for "disable" or you could set it to a very high value. If your Tomcat installation is still running in 32768 days, you certainly won't give a damn if it starts issuing warnings. -chris - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
Re: (tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
On 11/03/2024 21:38, schu...@apache.org wrote: This is an automated email from the ASF dual-hosted git repository. schultz pushed a commit to branch main in repository https://gitbox.apache.org/repos/asf/tomcat.git commit 3ab883aa746a5c577efa39d9080858e53ca77da6 Author: Christopher Schultz AuthorDate: Mon Mar 11 17:38:01 2024 -0400 Add checking for the age of the Tomcat version running and warn if it's getting old. How do I disable this check if I don't want to use it? I'd expect something like set it to "-1". Mark - To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
(tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
This is an automated email from the ASF dual-hosted git repository.
schultz pushed a commit to branch 8.5.x
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 83cef3de9b4d5288d7fbbf5852c324df31fab2de
Author: Christopher Schultz
AuthorDate: Mon Mar 11 17:38:01 2024 -0400
Add checking for the age of the Tomcat version running and warn if it's
getting old.
---
.../catalina/security/LocalStrings.properties | 3 ++
.../apache/catalina/security/SecurityListener.java | 63 ++
java/org/apache/catalina/util/ServerInfo.java | 18 +++
webapps/docs/changelog.xml | 5 ++
webapps/docs/config/listeners.xml | 5 ++
5 files changed, 94 insertions(+)
diff --git a/java/org/apache/catalina/security/LocalStrings.properties
b/java/org/apache/catalina/security/LocalStrings.properties
index 2af8b37d12..e356c44a27 100644
--- a/java/org/apache/catalina/security/LocalStrings.properties
+++ b/java/org/apache/catalina/security/LocalStrings.properties
@@ -18,6 +18,9 @@ SecurityListener.checkUmaskNone=No umask setting was found in
system property [{
SecurityListener.checkUmaskParseFail=Failed to parse value [{0}] as a valid
umask.
SecurityListener.checkUmaskSkip=Unable to determine umask. It appears Tomcat
is running on Windows so skip the umask check.
SecurityListener.checkUserWarning=Start attempted while running as user [{0}].
Running Tomcat as this user has been blocked by the Lifecycle listener
org.apache.catalina.security.SecurityListener (usually configured in
CATALINA_BASE/conf/server.xml)
+SecurityListener.buildDateAgeUnreadable=Unable to read configured
buildDateWarningAgeDays [{0}], using default of [{1}] days.
+SecurityListener.buildDateUnreadable=Server build date [{0}] is unreadable as
an ISO-8601 date.
+SecurityListener.buildDateIsOld=This version of Tomcat was built more than {0}
days ago. You should consider upgrading to the current version.
SecurityUtil.doAsPrivilege=An exception occurs when running the
PrivilegedExceptionAction block.
diff --git a/java/org/apache/catalina/security/SecurityListener.java
b/java/org/apache/catalina/security/SecurityListener.java
index 2371e30f7d..0fd20933b4 100644
--- a/java/org/apache/catalina/security/SecurityListener.java
+++ b/java/org/apache/catalina/security/SecurityListener.java
@@ -16,6 +16,10 @@
*/
package org.apache.catalina.security;
+import java.text.ParseException;
+import java.text.SimpleDateFormat;
+import java.util.Calendar;
+import java.util.Date;
import java.util.HashSet;
import java.util.Locale;
import java.util.Set;
@@ -24,6 +28,7 @@ import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Server;
+import org.apache.catalina.util.ServerInfo;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.buf.StringUtils;
@@ -42,11 +47,18 @@ public class SecurityListener implements LifecycleListener {
private static final String UMASK_FORMAT = "%04o";
+private static final int DEFAULT_BUILD_DATE_WARNING_AGE_DAYS = 180;
+
/**
* The list of operating system users not permitted to run Tomcat.
*/
private final Set checkedOsUsers = new HashSet<>();
+/**
+ * The number of days this Tomcat build can go without warning upon
startup.
+ */
+private int buildDateWarningAgeDays = DEFAULT_BUILD_DATE_WARNING_AGE_DAYS;
+
/**
* The minimum umask that must be configured for the operating system user
running Tomcat. The umask is handled as
* an octal.
@@ -126,6 +138,33 @@ public class SecurityListener implements LifecycleListener
{
return String.format(UMASK_FORMAT, minimumUmask);
}
+/**
+ * Sets the number of days that may pass between the build-date of this
+ * Tomcat instance before warnings are printed.
+ *
+ * @param ageDays The number of days a Tomcat build is allowed to age
+ *before logging warnings.
+ */
+public void setBuildDateWarningAgeDays(String ageDays) {
+try {
+buildDateWarningAgeDays = Integer.parseInt(ageDays);
+} catch (NumberFormatException nfe) {
+// Just use the default and warn the user
+log.warn(sm.getString("SecurityListener.buildDateAgeUnreadable",
+ageDays, DEFAULT_BUILD_DATE_WARNING_AGE_DAYS));
+}
+}
+
+/**
+ * Gets the number of days that may pass between the build-date of this
+ * Tomcat instance before warnings are printed.
+ *
+ * @return The number of days a Tomcat build is allowed to age
+ * before logging warnings.
+ */
+public int getBuildDateWarningAgeDays() {
+return buildDateWarningAgeDays;
+}
/**
* Execute the security checks. Each check should be in a separate method.
@@ -133,6 +172,7 @@
(tomcat) 02/02: Add checking for the age of the Tomcat version running and warn if it's getting old.
This is an automated email from the ASF dual-hosted git repository.
schultz pushed a commit to branch main
in repository https://gitbox.apache.org/repos/asf/tomcat.git
commit 3ab883aa746a5c577efa39d9080858e53ca77da6
Author: Christopher Schultz
AuthorDate: Mon Mar 11 17:38:01 2024 -0400
Add checking for the age of the Tomcat version running and warn if it's
getting old.
---
.../catalina/security/LocalStrings.properties | 3 ++
.../apache/catalina/security/SecurityListener.java | 63 ++
java/org/apache/catalina/util/ServerInfo.java | 18 +++
webapps/docs/changelog.xml | 5 ++
webapps/docs/config/listeners.xml | 5 ++
5 files changed, 94 insertions(+)
diff --git a/java/org/apache/catalina/security/LocalStrings.properties
b/java/org/apache/catalina/security/LocalStrings.properties
index 49dace925f..03906637c3 100644
--- a/java/org/apache/catalina/security/LocalStrings.properties
+++ b/java/org/apache/catalina/security/LocalStrings.properties
@@ -18,6 +18,9 @@ SecurityListener.checkUmaskNone=No umask setting was found in
system property [{
SecurityListener.checkUmaskParseFail=Failed to parse value [{0}] as a valid
umask.
SecurityListener.checkUmaskSkip=Unable to determine umask. It appears Tomcat
is running on Windows so skip the umask check.
SecurityListener.checkUserWarning=Start attempted while running as user [{0}].
Running Tomcat as this user has been blocked by the Lifecycle listener
org.apache.catalina.security.SecurityListener (usually configured in
CATALINA_BASE/conf/server.xml)
+SecurityListener.buildDateAgeUnreadable=Unable to read configured
buildDateWarningAgeDays [{0}], using default of [{1}] days.
+SecurityListener.buildDateUnreadable=Server build date [{0}] is unreadable as
an ISO-8601 date.
+SecurityListener.buildDateIsOld=This version of Tomcat was built more than {0}
days ago. You should consider upgrading to the current version.
listener.notServer=This listener must only be nested within Server elements,
but is in [{0}].
diff --git a/java/org/apache/catalina/security/SecurityListener.java
b/java/org/apache/catalina/security/SecurityListener.java
index 2371e30f7d..0fd20933b4 100644
--- a/java/org/apache/catalina/security/SecurityListener.java
+++ b/java/org/apache/catalina/security/SecurityListener.java
@@ -16,6 +16,10 @@
*/
package org.apache.catalina.security;
+import java.text.ParseException;
+import java.text.SimpleDateFormat;
+import java.util.Calendar;
+import java.util.Date;
import java.util.HashSet;
import java.util.Locale;
import java.util.Set;
@@ -24,6 +28,7 @@ import org.apache.catalina.Lifecycle;
import org.apache.catalina.LifecycleEvent;
import org.apache.catalina.LifecycleListener;
import org.apache.catalina.Server;
+import org.apache.catalina.util.ServerInfo;
import org.apache.juli.logging.Log;
import org.apache.juli.logging.LogFactory;
import org.apache.tomcat.util.buf.StringUtils;
@@ -42,11 +47,18 @@ public class SecurityListener implements LifecycleListener {
private static final String UMASK_FORMAT = "%04o";
+private static final int DEFAULT_BUILD_DATE_WARNING_AGE_DAYS = 180;
+
/**
* The list of operating system users not permitted to run Tomcat.
*/
private final Set checkedOsUsers = new HashSet<>();
+/**
+ * The number of days this Tomcat build can go without warning upon
startup.
+ */
+private int buildDateWarningAgeDays = DEFAULT_BUILD_DATE_WARNING_AGE_DAYS;
+
/**
* The minimum umask that must be configured for the operating system user
running Tomcat. The umask is handled as
* an octal.
@@ -126,6 +138,33 @@ public class SecurityListener implements LifecycleListener
{
return String.format(UMASK_FORMAT, minimumUmask);
}
+/**
+ * Sets the number of days that may pass between the build-date of this
+ * Tomcat instance before warnings are printed.
+ *
+ * @param ageDays The number of days a Tomcat build is allowed to age
+ *before logging warnings.
+ */
+public void setBuildDateWarningAgeDays(String ageDays) {
+try {
+buildDateWarningAgeDays = Integer.parseInt(ageDays);
+} catch (NumberFormatException nfe) {
+// Just use the default and warn the user
+log.warn(sm.getString("SecurityListener.buildDateAgeUnreadable",
+ageDays, DEFAULT_BUILD_DATE_WARNING_AGE_DAYS));
+}
+}
+
+/**
+ * Gets the number of days that may pass between the build-date of this
+ * Tomcat instance before warnings are printed.
+ *
+ * @return The number of days a Tomcat build is allowed to age
+ * before logging warnings.
+ */
+public int getBuildDateWarningAgeDays() {
+return buildDateWarningAgeDays;
+}
/**
* Execute the security checks. Each check should be in a separate method.
@@ -133,6 +172,7 @@
