> On 6 May 2021, at 11:26, Peter Firmstone <peter.firmst...@zeus.net.au> wrote: > > OpenJDK seems to have assumed that no one was using SecurityManager based on > one research report. There's a lot of closed source java code out there, I > suspect most of our users are closed source. I don't know exactly how many > compute nodes our users have, but it's 100's to 1000's, we seldom hear from > them, maybe a patch here or there, then you don't hear from someone for > years, and then you receive a patch. These users don't advertise they're > using our systems either.
While it is, indeed, our assumption that very few people use Security Manager, and fewer still use it for security, this assumption is not based not based just on one report, and, even then, it is a working hypothesis, and this JEP is a call for feedback. I do, however, think it is telling that so far, despite this proposal being quite well advertised, you are the only one who has stepped up and said that you’re relying on the Security Manager for security *and* find it hard to envision alternatives to an extremely complex mechanism designed for the sole purpose of running code with different permission levels in the same process, an approach that, over the last couple of decades has become disfavoured by both security experts and end-users. The marginal gain in security, if any, of giving different permissions to different portions of the same process does not justify the extra work, and even if it did, most people don’t do it. The Java ecosystem is huge, and most libraries simply don't work well with this mechanism. When the entire process has the same permissions — in line with current practice — there are superior sandboxes provided by the OS. > > Some feedback, we preserve context within Executor threads. > > AccessController scalability and performance is very good, we carefully > capture and re-establish security contexts in Executor threads. > Most performance issues have to do with the stack walking at the core of the Security Manager’s design. > > It's a shame that SecurityManager is crippled on Loom's virtual threads, I > was looking forward to using Loom for blocking network connections. Oh well, > scratch that Idea, we wouldn't be able to make TLS connections with them. I > was hoping Loom would reduce memory consumption, but then I haven't read > enough about it. We consume a lot of threads, one of the thread factory's at > least set the thread memory to a lower value than default to save memory. > Is Loom is designed to run small rapidly completing non blocking tasks? It is meant to run a great many concurrent tasks performing blocking operations (although they translate to non-blocking I/O once they reach the OS). Obviously, many of those will be short-lived, as you’d be able to spawn a new thread just for the purpose of, say, doing one HTTP client call. > > This is far less complicated than people are making out, it's not atomic > physics. Loom seems far more complicated than SecurityManager. Policy > features are added using policy decorators. After you look through these > implementations, you will see it's not that complex. Trying to convince people, at this point, after twenty five years that the Security Manager isn’t complicated after all might be too little too late. We know that, for reasons good or bad, very few people opt to use it, and that most who do, do it incorrectly. If, twenty five years from now, it turns out that Loom’s record is similar, I have little doubt that a similar proposal would be raised then. > > When Ron writes that SecurityManager is disabled on the common pool and > Loom's virtual threads, I hope he means that these threads have no > privileges, rather than all privileges? There is some documentation on the > common pool regarding SecurityManger, but little on Loom's virtual threads. > Can someone point me to a reference to security documentation on these > features please? That is correct. Here is where this is mentioned for ForkJoinPool: https://docs.oracle.com/en/java/javase/16/docs/api/java.base/java/util/concurrent/ForkJoinPool.html And here it is for virtual threads (the JavaDoc is still a WIP): https://download.java.net/java/early_access/loom/docs/api/java.base/java/lang/Thread.html#startVirtualThread(java.lang.Runnable) > > It is my opinion that removing the principle of least privilege will not > improve the security of our software, but rather degrade it. But then Java > hasn't had a good reputation for security in recent years, thanks to > Serialization, granted OpenJDK has done a lot to swat bugs as they're > discovered in recent years, it will take a little more time to build a good > reputation. Personally I wouldn't be removing SecurityManager, I'd be > addressing the issues and cleaning it up so programs can be run with > principles of least privilege, I know it's not perfect, but nothing ever is, > but it should improve with time, if it's not neglected and replaced if needed. There is nothing wrong with the principle of least privilege. Experience, however, has shown that relying on different code having different permissions *in the same process* is not a good strategy. After twenty five years of Security Manager with little use and less still proper use, and with most of the ecosystem not supporting this mechanism anyway so even if improvement were justified it would take years until people could enjoy it, increasing investment in it would be, in my opinion, throwing good money after bad. > > It's a shame it took SecurityManager's proposed removal for you to discover > it has practical application. You are right on one respect, not enough > people take security seriously. Security and the Security Manager are not the same thing, virtually none of the security work in the JDK in the past few years took place in the Security Manager, and the fact that it could be put to good use is irrelevant. That’s been true for twenty five years, and it is an empirical fact that the *actual* benefit gained from it does not appear to justify the investment it requires. At this point, extolling the virtues of the Security Manager’s design misses the mark. We know it is a fine piece of engineering. But we are not researchers and not in the business of proving a point; we are in the business of putting whatever resources we have where they’d do the most good to our users. What matters is the benefit SM actually has in the real world. A relevant argument in favour of keeping it would look like an impressive list of organisations that rely on it and cannot switch to simpler alternatives. — Ron
