> On 30 Apr 2021, at 04:42, Jeremy R. Easton-Marks <j.r.eastonma...@gmail.com> > wrote: > > I'm not sure how much JEP 411 will impact River. I agree with the overall > direction that it proposes in removing the security manager.
IMHO JEP 411 gives unconvincing reasons to ditch SecurityManager: - brittle permission model This one is really well summarized in the same paper: The Security Manager does not allow negative permissions that could express "grant permission for all operations except reading files”. Why not fix that??? Especially that it has been done before: https://github.com/olukas/pro-grade - poor performance Why not fix that??? Especially that it has been done before by… yes - Apache River (thanks Peter!). - difficult programming model This one is difficult to sensibly assess without comparing alternatives. Simply speaking: security is difficult - there is no free lunch. Example from the document (ie. client code needs to be granted permissions required by library code if doPrivileged is not used) has it completely backwards as that’s the whole point of stack walking based security: avoid confused deputee issue. It also looks like there is another huge misconception in the industry: "running untrusted code on the server is a big no-no and once you only run trusted code SecurityManager is not needed anymore”. The point really is: there is no such a thing as “trusted code” - that’s illusion. See for example: https://news.ycombinator.com/item?id=26087064 Similar misconception: one should avoid dynamically loaded code (or even from the JEP 411 itself: nobody is interested in dynamically loaded code). Well… Docker images _are_ dynamically loaded code. And k8s or Helm yaml descriptors defining what this dynamically loaded code can access are by no means simpler than security policy files. Quite the opposite. > However, I am > worried that removing security features is going to cause some other > problems in the Java ecosystem. Beyond the potential impact of River. > > I do think what affect it will have on Apache River should be explored. > > I am of the opinion that Apache River should look beyond just being a Java > only project and that we may need to rethink the way that we approach > building distributed systems. Killing mobile code is killing Apache River as IMHO that’s the defining feature of it. The question is whether killing SecurityManager is killing mobile code. Regards, Michal
