Re: JEP 411: Deprecate the Security Manager for Removal
On 19/05/2021 17:37, Robert Hicks wrote: Is that the "same" security manager we flip on for Tomcat or just an unfortunate naming coincidence? It is the same one. If you need the security manager I'd expect, based on typical lifetimes of Tomcat major versions, that you'd have a supported version of Tomcat where you could use a security manager in its current form for at least the next decade. Longer term solutions are still very much TBD. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JEP 411: Deprecate the Security Manager for Removal
Is that the "same" security manager we flip on for Tomcat or just an unfortunate naming coincidence? -- Bob
Re: JEP 411 Deprecate the Security Manager for removal
On 15/04/2021 21:03, Me Self wrote: Hi All It appears the security manager is going to be removed from a future release of java according to https://openjdk.java.net/jeps/411. That will be quite a chunk of code we could remove / would have to remove from Tomcat. When running Tomcat on Linux there are many excellent alternatives to locking down the JVM process with sandboxing/mandatory access control for instance Systemd and AppArmor and various LSM modules or even SELinux for the masochists. But what about Windows - I'm kind of blank here? The primary use case is to prevent Remote Code Execution attacks from spilling out into the OS. These attacks have been plentiful in some web frameworks (for instance struts2) and ĺibraries that are often used with Tomcat. Most of the severe ones we have had in the past fail in the presence of a sandbox because the remote code relies on privileged operations that are typically not permitted by the sandbox. The requirements for a sandbox I believe would be 1. Mandatory Access Control: Central configuration of security properties. Cannot be modified by the JVM process or user. 2. Principle of Least Privilege: Everything is forbidden except for explicit permissions that are granted for operations that are actually needed. 3. Preferably also with some level of app firewall built in. So does this exist for Windows? Run a VM? You can run a service as a custom user but I haven't looked at just how minimal the privileges for that user can be. Mark - To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
JEP 411 Deprecate the Security Manager for removal
Hi All It appears the security manager is going to be removed from a future release of java according to https://openjdk.java.net/jeps/411. When running Tomcat on Linux there are many excellent alternatives to locking down the JVM process with sandboxing/mandatory access control for instance Systemd and AppArmor and various LSM modules or even SELinux for the masochists. But what about Windows - I'm kind of blank here? The primary use case is to prevent Remote Code Execution attacks from spilling out into the OS. These attacks have been plentiful in some web frameworks (for instance struts2) and ĺibraries that are often used with Tomcat. Most of the severe ones we have had in the past fail in the presence of a sandbox because the remote code relies on privileged operations that are typically not permitted by the sandbox. The requirements for a sandbox I believe would be 1. Mandatory Access Control: Central configuration of security properties. Cannot be modified by the JVM process or user. 2. Principle of Least Privilege: Everything is forbidden except for explicit permissions that are granted for operations that are actually needed. 3. Preferably also with some level of app firewall built in. So does this exist for Windows?
