On 12/01/2023 09:23, Rémy Maucherat wrote:
On Thu, Jan 12, 2023 at 10:12 AM Mark Thomas <ma...@apache.org> wrote:
Hi all,
As you will have seen I'm starting to work on removing references to the
SecurityManager. Doing this has raised a couple of questions about
related features.
If there is no SecurityManager then everything deployed to Tomcat has to
be assumed to be trusted. Or Tomcat has to be run in an isolated
environment (container, VM, etc) with appropriate controls implemented
at the boundary of that environment.
If Tomcat operates on the basis of everything is trusted, do we still
need the following features:
- privileged property on Context
- ContainerServlet interface
- concept of restricted Servlets / Filters / Listeners
- configuration defaults that change when in "secure" mode
and probably several more I haven't come across yet.
Yes, it's probably going to take a while to figure out all the
consequences. These security features are not needed anymore in theory
since it is possible to cast and escape the jail. However, it could be
good to keep some (or maybe all !) for basic safety and encouraging
good practices. If the Tomcat internals are too readily available,
then we all know what happens ;)
It's a bit like the request/response facades. Of course they are there
to enforce a real isolation between webapps (this part is no longer
required), but they can also be used to prevent unintended access
(async use, and so on).
Ack.
For the configuration defaults that change depending on whether Tomcat
is in "secure" mode how do we want to control this? An attribute on the
SecurityListener? That would make the change back-portable (with the
default in earlier versions depending on whether the security manager is
set).
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
