The permission which the SecurityManager will check when code that
is running with a SecurityManager calls methods defined in the
module system for the Java platform.
The following table provides a summary description of what the
permission allows, and discusses the risks of granting code the
permission.
| Permission Target Name |
What the Permission Allows |
Risks of Allowing this Permission |
| releaseModule |
Release an existing module instance from the module system via calls to
the ModuleSystem releaseModule method. |
This is a dangerous permission to grant.
Malicious applications that allows an attacker to
release an existing module instance, so the
runtime characteristics of the Java virtual
machine is changed and it could cause the system to
misbehave. |
| disableModuleDefinition |
Disable a module definition in the module system via calls to
the ModuleSystem disableModuleDefinition method. |
This is an extremely dangerous permission to grant.
Malicious applications that allows an attacker to perform
denial-of-service attack by disabling a module definition,
so the existing module instance is released, and also disallows
the module system from creating a new module instance from
that disabled module definition. |
| installModuleArchive |
Install a module archive in a repository via calls
to the Repository install method. |
This allows an attacker to install malicious code
into the repository of the module system. |
| uninstallModuleArchive |
Uninstall a module archive in a repository via calls
to the Repository uninstall method. |
This allows an attacker to remove critical module
definitions from the repository of the module system. |
| listModuleArchive |
Discover the installed module archives in a repository via calls
to the Repository list method. |
This allows an attacker to discover the installed module archives
in the repository of the module system. |
| createRepository |
Creation of a repository. |
This is an extremely dangerous permission to grant.
Malicious applications that can instantiate their
own repositories could then load their rogue
modules and classes into the module system. |
| shutdownRepository |
Shutdown a repository. |
This allows an attacker to shutdown a repository
so the repository can no longer serve any module
definition. |
| reloadRepository |
Reload module definitions in a repository. |
This allows an attacker to invalidate the lifetime of
the outstanding module instances instantiated from
the module definitions in the repository. |
| accessModuleDefinitionContent |
Access the actual content of the module definition. |
This allows an attacker to have access to the actual content
of the module definition in the repository. |
| setImportOverridePolicy |
Change the default import override policy in the module system. |
This allows an attacker to choose specific versions of imported
modules when a module instance is initialized. |
Programmers do not normally create ModuleSystemPermission
objects directly. Instead they are created by the security
policy code based on reading the security policy file.
java.security.Permission