builtin class loaders and security manager

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

builtin class loaders and security manager

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?

Reply | Threaded
Open this post in threaded view
|

Re: builtin class loaders and security manager

Alan Bateman
On 13/10/2018 19:55, Michał Zegan wrote:
> 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
Reply | Threaded
Open this post in threaded view
|

Re: builtin class loaders and security manager

Michał Zegan


W dniu 14.10.2018 o 09:12, Alan Bateman pisze:

> On 13/10/2018 19:55, Michał Zegan wrote:
>> 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.
>
> -Alan