Thanks Alan, comments inline below.
On 26/10/2022 11:07 pm, Alan Bateman wrote:
:
What would make a significant difference is returning non null
ProtectionDomain's for JDK modules, so we can reduce the size of the
trusted computing base, to make our job smaller, hopefully that will
allow focusing on placing authorization checks on the low level
access to file systems and networks, which are our main concerns.
The PD should not be null, maybe you mean the CodeSource? I think we
exchanged mail about this before and it might be generally useful to
have that. It would mean working through some issues related to patching.
Apologies, you are correct, a non-null CodeSource in system PD's.
Thank you for remembering :)
:
Do you think that tighter module boundaries will negate the need for
RuntimePermission accessClassInPackage.* below?
This is only needed when running with a SM.
I will need to assess each before I decide whether it warrants
instrumenting or not. Authorization controls aren't really the right
tool for this, it feels like a hack, it belongs under language
visibility controls, such as module boundaries. In our system,
authorization will only grant dynamic class loading to authenticated and
authorised entities, so some of these things might belong under
monitoring and reporting. We can also require that dynamically loaded
code is signed, the signer certificates for code can be communicated
after authentication, before dynamically loading code, so we don't
require a Certificate Authority for code certs. We're not running
untrusted code, but we do use PD's to represent a remote service, that
has a presence in the local JVM, which may or may not include code.
Regards,
Peter.
