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.
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.
Mark
But, you could always use JNI and a C++ module to do nearly everything
with the bytes in memory. Should we think that far? That would be a
killer argument against using any sensitive data with Tomcat, Java or
even computers in general :-)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org