On 05/09/2024 22:25, Konstantin Kolinko wrote:
пн, 19 авг. 2024 г. в 14:27, Mark Thomas <ma...@apache.org>:
On 19/08/2024 12:23, ma...@apache.org wrote:
Author: markt
Date: Mon Aug 19 11:23:05 2024
New Revision: 1920023
URL: http://svn.apache.org/viewvc?rev=1920023&view=rev
Log:
Add first draft of security model
All,
This is an attempt to document something I think we all instinctively
understand. It is likely that we'll need this, or something like it, to
meet the CRA requirements (or to be more accurate for our downstream
users to meet their CRA requirements).
It is currently not linked from the rest of the Tomcat site. My thinking
was we'd refine it and then link it once we were happy with it.
Feel free to update/comment/etc just like any other site content.
Thank you for starting this work.
BTW, url for the document (if somebody wants to review) is
https://tomcat.apache.org/security-model.html
Some thoughts
- In "Administrative users" there it says "has access to or control over".
I was wondering whether it could be simplified, but I resolved to
leave it as is.
Generally, "read access" should not be allowed to Tomcat configuration
files, as those may contain secrets.
Read access to the binaries generally is safe, but may be used to
determine what version of Tomcat is being used.
If so, are users that have access to those considered as "Administrative users"?
TL;DR: yes.
There are different levels of risk for different files. Users may well
opt to apply different access controls to different files. Our position
is (as I understand it) if any of those users can do harm as a result of
that access then that is not a Tomcat vulnerability. The simplest way to
express this is to state that any vulnerability that relies on access to
those files will be rejected.
- Maybe mention the temporary files (temp, work).
Though they are mentioned on the Security Considerations pages.
"temp" is used for Servlet API's file upload support and for the
antiResourceLocking feature. "work" stores compiled code for the web
applications that we consider as "trusted".
Good idea. Done.
- In "Logging" I wonder what "Security-sensitive information" is.
I was trying to distinguish between information an attacker can use to
gain access (e.g. a password, session ID etc) and everything else.
Non-anonymised information about users' activity is generally
sensitive, and thus are access logs.
We do log IP addresses. We do log "%u" (user name).
In general non-trusted users should not have access to that information.
I'll add a note that the default logs contain PII.
BTW,
generally "non sensitive" data may actually be sensitive, if users may
put sensitive information into it. (E.g. I vaguely remember that I
once saw a system that logged names of users that failed to
authenticate, and some users were typing their passwords into the
username field, resulting in those being logged). (IIUC, %u is safe,
as it logs names of those who have successfully authenticated)
I've seen that too. I've added a note that Tomcat isn't responsible for
the content of log messages generated by applications so we aren't
required to sanitize them.
- In Connectors, maybe mention that AJP is essentially plain text, as
well as plain HTTP or plain HTTP/2 (h2c).
I think that is straying more into something that belongs in security
considerations. I've may an update there that I'll commit once I've
finished updating this page.
- I wonder whether "Data .. is considered to be untrusted" has further
exceptions.
I couldn't think of any but we can add to it if necessary.
A front proxy may reuse connections to Tomcat to process requests from
different clients. We do expect the data to be structurally correct.
I've added paragraph to say that it is the client's problem if it
presents malformed data and doesn't handle the response correctly.
Minor
- I wonder whether the "apart from" clause (in Connectors) is
understandable. I considered rewriting it as "with exception of the
following".
To a native speaker there isn't any difference but happy to change this
if it is more likely to be understood by a wider audience.
Generic, beyond bounds of this document.
- When I think about what "trust" actually means and implies, it
inspires some related thoughts / topics.
(How the trust can be enforced. What happens when trust is breached. Etc.)
Fortunately that is not our problem ;)
- I wonder whether there exists a "Security Model" document for a
generic web application.
I haven't seen one.
As always, thank you for the thorough review.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
