On 18/05/2021 10:21 am, Ron Pressler wrote:
On 18 May 2021, at 01:11, Peter Firmstone <peter.firmst...@zeus.net.au> wrote:
Your ideas are great in theory, in practice, the problem with your Agent
proposal is every JVM release needs to be reviewed, and we have to review
Java's internal implementation code, and understand it in order to instrument
it.
Absolutely. But that is exactly the work OpenJDK maintainers are required to do
today to support something most
people want better alternatives for at the expense of those better alternatives
and other work.
Yes, I realize that, it is my understanding that because this is a
security concern, it is not something the community is allowed to
provide support for at OpenJDK, hence my suggestion to Alan, to make it
possible for this to happen by changing the security level and calling
it an access control layer concern.
Also is OpenJDK using static analysis to spot bugs? Just out of
curiosity, it's something we do for our code.
POLP isn't perfect, I acknowledge that, but it's much better than
nothing as it does assist to limit damage in the event of an attack. If
this is the only issue, I'm sure the community will be willing to
assist. It would be less work for me to maintain the existing
implementation than try to re-implement this functionality in a
relatively compatible way. I would review OpenJDK's permissions as
well, given that I use doPrivileged and POLP regularly, it's probably
going to be more obvious to me where bugs are, I do see evidence of
these bugs in my policy file generation, so I would be able to fix a
number relatively quickly.
Unfortunately for us to put these proxy's into separate processes, in
order to use OS level access control, we could have hundreds to
thousands of processes running. So it's not really an option. We would
still need to communicate with that process, so it's starting to make it
difficult to manage secure connections etc.
ClassLoader's are so lightweight in comparison to a process.
Our RFC 3986 and RFC 5952 URI based ClassLoader is also so much faster
than URLClassLoader, so it's not just security performance, I looked for
hotspots and eliminated all of them. Where OpenJDK is doing dns
network calls, we normalize ASCII strings. It's AL2.0 licensed code
refactored from Harmony, so I don't think it's an option for OpenJDK.
We'd like to avoid performance penalties as well, other options proposed
have unknown performance costs, which may be significantly worse than
current performant and scalable code. Remember our performance
limitations are JVM native sockets, if you look at our hotspots, they're
all JVM native methods.
While I admit that what we do with distributed software isn't commonly
done in modern software, as most gave it up as too difficult years ago,
we persisted and solved some very difficult problems.
Maybe if you put hooks (annotations?) into the JVM code, so it was easier for
agents to know which calls need to be controlled for access decisions? But
then if not many people are using it, it will suffer neglect.
Yeah, it sounds neither here nor there, but the relevant maintainers will
consider it.
It may be the deciding factor for us, so I'd appreciate it if this can
be considered.
Is it also possible to consider directing file access and network access
through single points of access? This will simplify the process so we
don't need to scour the entire codebase for usages.
What about doPrivileged calls? Will they remain in existing Java
library code, so we can utilise them? To avoid viral permission
propagation?
It's your existing userbase with over 50% still using Java 8 that need
convincing, who will be ultimate judge of the success or failure of this
decision.
If you have data that contradicts our estimate of Security Manager usage among
Java 8 users, please present it.
- Ron
I don't know what data you have, it's not something I've considered
polling, if I find anything, I will most certainly share it.
--
Regards,
Peter Firmstone
