You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Mark Thomas <ma...@apache.org> on 2023/01/12 09:10:12 UTC
SecurityManager removal
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.
Thinking about it logically, none of the above features are required in
an environment that doesn't have a SecurityManager so they should all be
removed. Despite that, I still have a nagging feeling I am missing
something.
Thoughts?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: SecurityManager removal
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: SecurityManager removal
Posted by Rémy Maucherat <re...@apache.org>.
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).
Rémy
> Thinking about it logically, none of the above features are required in
> an environment that doesn't have a SecurityManager so they should all be
> removed. Despite that, I still have a nagging feeling I am missing
> something.
>
> Thoughts?
>
> Mark
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org