Overview |
|
On Windows, access to system resources and system-related tasks can be controlled with privileges held in an object called access token. When the Wrapper is executed on behalf of a user, the process receives a copy of the access token containing the user's privileges. The Professional Edition of the Wrapper makes it possible to adjust these privileges at different levels:
For security, it is recommended that an application enables only the privileges that it needs. If a privilege may be used occasionally, or if it must be used by some of its child processes, it can be disabled to retain the ability to re-enable it at a later stage. However, to prevent a privilege from being re-enabled by the application or any of its child processes, the safest course of action is to remove the privilege completely. If no required privileges are specified for a Windows Service, the SCM will not change the service's access token at startup, leaving it with the privileges assigned by default, i.e those held by the user and groups to which the service account belongs. The following privileges are commonly assigned to users running services:
In general, the above privileges are appropriate (and sometimes necessary) for the Wrapper process, so in most situations you should not need to change them. However, depending on your application usage, it may be better for security to remove some privileges from the access token of the Java process or child processes running in response to events. ADVERTENCIAParticular attention should be paid to the SeImpersonatePrivilege privilege. While enabled by default for Windows services, this privilege can be abused to escalate from a local account to NT AUTHORITY\SYSTEM if the Java application gives the user the ability to execute arbitrary commands. In such cases, it is highly recommended to remove SeImpersonatePrivilege from the Java process. The same applies to Event Commands. Caution should always be taken to ensure that the target program or script has appropriate file permissions so that it cannot be modified or replaced. But, additionally, if the configured command gives the user the ability to execute its own commands or open a console, the SeImpersonatePrivilege should also be removed. NT AUTHORITY\SYSTEM is a powerfull account that has even more privileges than an Administrator on Windows. Gaining access to it is a real safety concern, as it would allow almost full control over the machine.
Please see the description of the wrapper. The following properties are available to configure privileges:
|
Required privileges for a Windows Service |
||||||||||||
|
Runtime privileges for the Wrapper process |
||||||||||||||||||||||||||||||||||||||||||||||||
|
The following properties are used to adjust privileges for the Wrapper process. Only privileges that exist in the access token of the Wrapper process can be adjusted. By default, the access token contains the privileges held by the user under which the Wrapper is running and the privileges of the groups to which this user belongs. For Windows services, the default privileges can be overridden by setting a list of required privileges. If a privilege is missing, it is possible to add it to the wrapper.ntservice.required_privileges list and to re-install or update the service. On the next startup, the access token of the Wrapper should then contain the privilege. Note that these properties will only take effect on the first configuration load and will be ignored if the configuration is reloaded.
|
Runtime privileges for the Java process |
||||||||||||||||||||||||||||||||||||
|
The following properties are used to adjust privileges for the Java process. If any of these properties are set, the access token of the Wrapper process will be duplicated and the specified privileges will be adjusted in the token copy. The Java process will then be launched in the security context represented by this new token. Only privileges that exist in the access token of the Java process (and therefore also exist in token of the Wrapper process) can be adjusted. Keep in mind that the list of privileges can be changed at two levels before the Java process is launched: when installing a Windows service if required privileges were specified, or if one or more privileges have been removed when starting the Wrapper. The privileges will be readjusted each time a new JVM is launched. If reloading the configuration file is allowed, these properties can be changed to use different privilege settings on the next JVM invocation.
|
Runtime privileges for Event commands |
||||||||||||||||||||||||||||||||||||||||||||
|
The following properties are used to adjust privileges for commands launched in response to certain events. If any of these properties are set, the access token of the Wrapper process will be duplicated and the specified privileges will be adjusted in the token copy. The event command will then be launched in the security context represented by this new token. Only privileges that exist in the access token of the Event command (and therefore also exist in token of the Wrapper process) can be adjusted. Keep in mind that the list of privileges can be changed at two levels before an event command is launched: when installing a Windows service if required privileges were specified, or if one or more privileges have been removed when starting Wrapper. NOTAThe ability to control privilege at different levels when processes are launched allows configurations like the following: In order to enable a certain privilege for an Event Command, it must also exist for the Wrapper process. However, the Java process can completely remove this privilege, thus ensuring that it won't be used by the Java application nor by any of its child processes.
|
Query the privileges of a Windows Service |
||||||||||||
It is possible to query the required privileges of a Windows service, as well as the runtime privileges of the Wrapper process and its child processes, with a single command: .\wrapper.exe -qr .
It is also possible to query the privileges of a different service by adding '=', followed by the service name, to the -qr option ('-qr=serviceName').
|