On 6/05/2021 9:46 pm, Ron Pressler wrote:
Most performance issues have to do with the stack walking at the core of the
Security Manager’s design.
I disagree, unless you can provide /evidence or context, I have not seen
any evidence for this, I've done a lot of performance testing on the
security infrastructure over the last 10 years.
When SecurityManager is enabled, with the default policy provider,
synchronization in PermissionCollection::implies checks are a huge
scalability bottleneck.
I have not seen any performance bottlenecks from stack walking in hot
spots in my tests, unless you call 2% a hotspot. Although I do allow
for hotspot to warm up to make optimisations. Are you talking
micro-benchmarks? Prior to hotspot optimization?
Do you have any performance tests results I can look at?
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.
Ok, this does sound useful.
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.
That's not my concern, you made the argument it was impossible, that
there were no working implementations, I think you concede now that
isn't the case, therefore job done. You have a vested interest in its
removal, so you attempt to downplay the impact it will have on Java
developers, I have a vested interest in reducing the maintenance burden
I have too.
My concern is software compatibility. The newly proposed API's only
replaces existing functionality, and it does so in a way that is not
backward compatible. It offers no new features, it only lessens
OpenJDK's maintenance burden, while causing a huge maintenance burden
for downstream projects.
The proposed changes not only impact those who use SecurityManager, but
will also impact anyone that uses the current sign in mechanisms, and
use the Subject for TLS connection authentication as well as Kerberos.
Shotgun surgery and breakages go far beyond SecurityManager alone.
Why not simply document it instead as I have suggested in my reply to
Alan and treat the bugs differently to reduce maintenance cost?
No new API's are needed then.
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)
Can I use doPrivileged blocks with context, or will they be
innefective? If yes to the former and no to the latter, then it's great
these threads have no permission by default.
Just trying to work out if I can use it with secure network connections?
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.
Experience with poor or incomplete implementations has shown that. You
have to admit then, that you have zero experience with a good
implementation.
It's just access control, you are mistakenly still thinking about
sandboxes. In the sandbox model, the sandbox is the be all and end all
of security, the sandbox is supposed to present a safe and impenetrable
api, in the cheese model, access control is just one layer of cheese
with holes. Because nothing is perfect, it's better to have multiple
layers of security, as it reduces the chances of things like gadget
chains succeeding, rather than a be all and end all wack-a-mole
whitelist approach that seems to be popular of late.
https://securityandpeople.com/2017/07/human-errors-in-cyber-security-a-swiss-cheese-of-failures/
Anyone can use JGDMS to enjoy it now, little investment is required, the
work is done. It also takes the pain out of implementing TLS
communications as well, including preserving the Subject across JVM's.
https://github.com/pfirmstone/JGDMS
It supports Maven and OSGi, so you can dynamically download libraries
and automatically assign permissions. Haven't implemented support for
Java modules yet, as we still compile on Java 8, although funnily enough
we use later TLSv1.3 cypher suites.
Oh, that reminds me OSGi also implements SecurityManager and has dynamic
permissions, it can revoke as well as grant permissions, are you aware
of it? It uses a different mechanism though, because it pre-dates Java
1.4, I don't recall the implementation.
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,
Agreed, but your statement is not relevant to the points I'm making
here, you are still thinking about sandboxes, instead of access
control. Sandbox whitelists is wack-a-mole, so is white listed
Serialization without atomic failure input validation. Maybe it's not
that people don't take security seriously, it's that they think white
lists are an appropriate form of security, without authentication and
validation, they are not. Same problem with the sandbox. Access
Control is still useful, when it's not treated as the front line of
security, but a more rearward layer that is expected to have holes,
because it has limitations, so we instead depend on a armory of defense
layers, each with flaws, that we try to manage. The Cyphers of the late
90's are no longer in use, and neither is the sandbox.
virtually none of the security work in the JDK in the past few years
took place in the Security Manager,
Because Serialization is not failure atomic, is performed by privileged
system code and developers had open network ports without authentication
that an attacker could intercept and use gadget chains to take over the
JVM, I don't see how this is relevant to access control for trusted code
and trusted users. There were similar problems with XML. This is why
whitelists and whak-a-mole is not security either, also why I think
whitelist serialization will come back to bite again, because people
using whitelists think they can process data, without proper input
validation. What makes it works is it's a separate concern, it breaks
object encapsulation.
There should be a command line parameter to disable Serialization, in
such a way that it cannot be enabled at runtime.
--
Regards,
Peter Firmstone
Zeus Project Services Pty Ltd.
