Discussion:
builtin class loaders and security manager
Michał Zegan
2018-10-13 18:55:29 UTC
Permalink
Hello,
I seem to be asking many questions lately, although I am actually
interested in some motivations. I was reading code of builtin class
loaders, and from what I understand from that, it seems that classes
loaded by builtin class loader including app class loader, if loaded
from a signed jar, are properly verified, however signers are not
retained in CodeSource. Is this intentional/why?
Alan Bateman
2018-10-14 07:12:59 UTC
Permalink
Post by Michał Zegan
Hello,
I seem to be asking many questions lately, although I am actually
interested in some motivations. I was reading code of builtin class
loaders, and from what I understand from that, it seems that classes
loaded by builtin class loader including app class loader, if loaded
from a signed jar, are properly verified, however signers are not
retained in CodeSource. Is this intentional/why?
The support for signed modules is very limited at this time. The
signatures are checked but the code source in the protection domain
doesn't have the signers - this is tracked as JDK-8194930. To do that
right may require adding a codeSigners method to ModuleReference or
ModuleReader. There is further work needed at link time and in the
runtime image to support linking of signed modules into a run-time
image. Just hasn't been a priority to date and would need someone
willing to put in significant time to work on the various pieces.

-Alan
Michał Zegan
2018-10-14 11:30:37 UTC
Permalink
Post by Alan Bateman
Post by Michał Zegan
Hello,
I seem to be asking many questions lately, although I am actually
interested in some motivations. I was reading code of builtin class
loaders, and from what I understand from that, it seems that classes
loaded by builtin class loader including app class loader, if loaded
from a signed jar, are properly verified, however signers are not
retained in CodeSource. Is this intentional/why?
The support for signed modules is very limited at this time. The
signatures are checked but the code source in the protection domain
doesn't have the signers - this is tracked as JDK-8194930. To do that
right may require adding a codeSigners method to ModuleReference or
ModuleReader. There is further work needed at link time and in the
runtime image to support linking of signed modules into a run-time
image. Just hasn't been a priority to date and would need someone
willing to put in significant time to work on the various pieces.
My opinion is that at least the first part of it should be done, as it
is the easiest and least problematic (probably?) especially that all
module readers I know (implemented in jdk) use the JarFile class to
process jars, so have access to the needed information. The part about
runtime images and linking may be more problematic.
Post by Alan Bateman
-Alan
Loading...