Mark,
On 5/28/21 04:13, Mark Thomas wrote:
On 28/05/2021 07:22, Carsten Klein wrote:
Chris, Mark,
On 27/05/2021 22:11, Christopher Schultz wrote:
</snip>
After re-reading this, you mentioned reflection while asking how much
we trust in Collections.unmodifiableMap(). I didn't get that right, my
bad.
However, I thought of reflection in order to implement a deep copy
mechanism. Maybe anyone already coded one on jpm? :)
If we return Collections.unmodifiableMap() to return
Map<String,String> that makes things simpler. But how much do we
trust Collections.unmodifiableMap if the underlying data are
security-sensitive? With reflection, is it possible to monkey your
way through the references and swap-out the underlying references?
That might be Bad.
The question is, what kind of security problem are we actually trying
to prevent? It is clearly not leak of information, since the
administrator is responsible for what attributes are configured to be
gathered. The administrator should clearly not provide sensitive
information that should not be seen by the public. If so, his bad :-p
Needless to say that I plan to deny querying passwords with that new
Realm feature? Attribute names, for which I know they refer to fields
containing passwords (like whats set for DataSourceRealm's option
userCredCol), will *never* be queried.
So, security here is about preventing that someone can modify that
information during that Principal's lifetime. Can you modify an
immutable object with reflection? Not sure.
You can. But. In a scenario where that is a risk you need to mitigate,
you would be running under a SecurityManager which would block access to
reflection.
Yeah, about that...
https://openjdk.java.net/jeps/411
IMO this is a Bad Thing for Java. If someone was looking for a reason to
abandon the whole Java ecosystem, this would be it. Well, we had a good run.
Now we can all run node.js, Python, or Go where security is not a
problem because the languages are "safe" so nothing Bad can happen,
right? *facepalm*
Generally, the "running untrusted apps" risk isn't one that most users
face but it a use case that Tomcat aims to support so we have to keep it
in mind.
In this case, ensuring that the caller can't modify the source data and
thereby influence the result of future calls - e.g. by making defensive
copies or ensuring objects are immutable - is sufficient to maintain
Tomcat's security model.
+1
For now, Tomcat can rely on the SecurityManager doing its job. That
means we only need to rely on the encapsulation strategies the language
and the standard library provide, which are (currently) sufficient.
-chris
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
