I also think good developers will add these security features.
The problem is that Permissions are currently used to regulate access
control because this is how we've been told it should be done for over
20 years.
Now maybe people aren't using the Java FilePolicy provider (for reasons
stated previously), but as has been discovered, they often will override
SecurityManager and implement some form of access control on trusted 3rd
party code.
Trusted code - Developed by people with good intentions - includes third
party library code, we check it for known vulnerabilities at build time
using OWASP, but we don't audit it ourselves as this requires
understanding how the internals work and we are using it like a black
box. If we have concerns we might perform static analysis, but we don't
do that for dynamic code, eg maven dependencies and then we are
powerless to do anything about it, other than report the bug, so access
control can be used to mitigate until it's fixed, or we can use the
principle of least privilege so we are not impacted by it.
Java Serialization is also a form of parsing information, just like PDF
documents and other file formats, problems with the Sandbox; there was
no Permission to limit which classes could be deserialized, and JVM code
always has AllPermission, so we couldn't restrict it either.
Additionally there was no ProtectionDomain to represent the data being
deserialized, and whether it was trusted or untrusted, these security
features wouldn't have been difficult to add, however we rely on the
platform developers to see the benefits. We are all only human.
In JGDMS there are constraints we apply to services which require
authentication and encryption, which must be met before deserialization
or any downloads can proceed.
In our re-implementation of Atomic Java Serialization, we use a
DeserizablePermission, to limit which libraries can perform
de-serialization. This is in addition to the use of failure atomic
constructors, so we don't break object encapsulation.
We also perform static analysis at build time and fix these bugs too.
SecurityManager has much influence in access decisions in our software,
we won't have the resources to upgrade, there's a massive amount of
security auditing required before we could even consider it. Our only
option is to participate in the maintenance of existing Java versions.
Java will be our COBOL. We will be capable of using Java 1.8 to 1.17,
but not Java 2.0 (after disablement occurs).
Obviously removing SecurityManager infrastructure from OpenJDK is a
significant undertaking requiring significant resources to audit the
impacts of removal of Permission checks, unfortunately we don't have
these resources and the alternative methods of putting alternative
access controls in place isn't obvious and will require research, as you
state below, I know very little about how this can be done without using
existing Java access controls.
I think during this transition period, while developers are
reestablishing what constitutes secure programming, there will be many
new bugs exposed that SecurityManager was obscuring.
Personally, I will be observing from the sidelines to learn new security
features and best practices I'm not yet aware of. It's always best to
wait and see the outcome of experiments before diving in.
The problem with Security is many developers don't like it, or want it
to be someone else's problem, so we will always have reasons to remove
whatever Security API's are added to Java because of limited use.
Perhaps I'm conflating security with access control again?
--
Regards,
Peter
On 14/05/2021 2:15 am, Sean Mullan wrote:
On 5/12/21 5:41 PM, Peter Tribble wrote:
Let me give a concrete example:
Parsing and rendering a PDF file that may contain references to fonts
or other resources.
We know exactly where the files are installed, so wish to allow the
rendering routine access
to the fonts it will need. But not to any other files, and not
(normally) to network resources at
all. Note that we trust the code, but not necessarily the document
it's parsing. (Although the
document itself may be perfectly well formed - document formats often
allow embedding
references to 3rd-party objects, undesirable as that may be.)
There are a range of such issues in document parsing and rendering.
And unfortunately, the
good libraries for this task are proprietary so we can't modify them
to apply the restrictions
we're after. The (server-side) application does need access to files
and network resources at
other times; it's only when it goes into the rendering step that we
lock it down, and unlock it
once done.
I know very little about this area, but I would think a good PDF
rendering library would include security features which prevent
arbitrary file/network access from untrusted documents by default or
at least give you the ability to control that.
--Sean
