The Snow Inventory Java Scanner (SIJS) can be configured to run at three different security levels: LOW, MEDIUM, and HIGH. This article explains how the Java scanner gets its information, why security levels exist, what they do, and why you might want to change the configuration.

How the Java scanner works

SIJS identifies Java installations by executing the Java binaries it finds and querying them directly for version details.

Ideally, SIJS runs the following command: java -XshowSettings:properties -version

Older Java versions do not support this command, so SIJS falls back to a more compatible option: java -version

Why security levels exist

Prior to the introduction of Java security levels (before SIJS 2.0.0), all Java binaries discovered by the scanner were executed in the same security context as the scanning user. For example, if the scanner were run as an administrator or root user, every discovered Java binary would also be executed with those privileges. This behavior introduces security risks. A binary named java.exe may not be a legitimate Java executable and could potentially be malicious. Executing such a binary with elevated privileges presents an obvious security concern. Java security levels were introduced to mitigate this risk.

Trusting Java binaries

SIJS determines whether a Java binary is trusted based on where it is found.

Admin path

• If the full path to a Java binary exists in the scanning user’s PATH environment variable, SIJS assumes that the Java installation was intentionally installed or configured by an administrator.
• These binaries are considered trusted and are referred to as being found in an admin path.
• The Java executable used to run SIJS itself is also automatically trusted.

Non-admin path

• If the Java binary is not found in the scanning user’s PATH, SIJS cannot determine how it was installed and does not assume it is trusted.
• These binaries are referred to as being found in a non-admin path.
• The scanner uses this trust determination to decide whether and how a Java binary is executed, depending on the configured security level.

Security level behavior

HIGH

• Java binaries found in an admin path are executed in the same security context as the scanning user.
• Java binaries found in non-admin paths are not executed. A message is displayed in the All Java Installations report indicating that the scan was blocked.

MEDIUM

• Java binaries found in an admin path are executed in the same security context as the scanning user.
• Java binaries found in non-admin paths are executed with reduced privileges:
  • Windows: Uses runas /trustlevel:0x20000 to execute the command as a basic user.
  • Unix / Linux: Switches to the user defined by the ImpersonationUser setting.

LOW

• All Java binaries are executed in the same security context as the scanning user, regardless of where they are found.

Example (Windows)

The All Java Installations report shows two Java installations on a system.

The first installation is recognized and includes vendor, version, and full version details.

• Home path:
  • C:\Program Files\Eclipse Adoptium\jre-8.0.432.6-hotspot
• The second installation is inventoried with issues and does not include detailed version information.
  • Message displayed:
    Scan not allowed for this security level – non-admin path
  • Home path:
    C:\Program Files\sqldeveloper\jdk\jre\bin\java.exe

This message indicates that the Java binary was found in a non-admin path and was not executed due to the configured security level. Reviewing the Java scanner configuration in snowagent.config (or sijs.config prior to SIJS 3.4.0) shows that SecurityLevel is set to HIGH.

Checking the PATH environment variable on the client confirms that:

• C:\Program Files\Eclipse Adoptium\jre-8.0.432.6-hotspot\bin is present
• C:\Program Files\sqldeveloper is not present

If you have a Snowpack but no access to the client, you can check there as well:

Because the scanner ran at HIGH:

• The Eclipse Adoptium Java was found in %PATH%, so it was trusted and ran in the same security context as the scanning user.
• The SQL Developer Java installation was in a non-admin path (it does not appear in %PATH%), so it was not trusted and was not executed.

Effect of changing to MEDIUM

When the security level is changed to MEDIUM, both Java installations are fully recognized.

At this level:

• The Eclipse Adoptium Java binary is found in %PATH% and is executed in the scanning user’s security context.
• The SQL Developer Java binary is found in a non-admin path and is executed with reduced privileges using runas /trustlevel:0x20000.

As a result, both installations are inventoried successfully.

Behavior at LOW

If the scanner is run at LOW:

• All Java binaries are trusted.
• All binaries are executed in the same security context as the scanning user, regardless of whether they are found in admin or non-admin paths.

Linux, Unix, and macOS behavior

On Linux, Unix, and macOS systems, runas /trustlevel is not available. At MEDIUM security, SIJS instead switches to a standard user account defined in the configuration.

Configuring the impersonation user

<ImpersonationUser>javascan</ImpersonationUser>

By default, SIJS uses javascan as the impersonation user. This value can be changed as needed.

The specified user account must exist on the system and have permission to execute any Java binaries that may be discovered.

Example logging

MEDIUM security, non-admin path (Windows)

Trace; Scanning paths; se.snow.javascanner.command.CmdExecutor; executeCommand;
Executing system command:
[cmd, /c, cd "C:\Users\ROBERT~1.URQ\AppData\Local\Temp\snow\sijs\sijs4351872585328171740\"
&& runas /trustlevel:0x20000 /machine:amd64
"cmd /c \"C:\Program Files\sqldeveloper\jdk\jre\bin\java.exe\" -XshowSettings:properties -version
> 16e482dd-92ac-466d-8d4d-1ba926519e77.txt 2>&1"]

MEDIUM security, non-admin path (Linux)

Info; Scanning paths;;; Number of non-admin paths: 12 Trace; Scanning paths; se.snow.javascanner.command.JavaExecutor; getJavaProperties; 
Getting java properties from path: /usr/local/jdk1.7.0_80/jre/bin/java Trace; Scanning paths; se.snow.javascanner.command.CmdExecutor; executeCommand; 
Executing system command: [/bin/sh, -c, su javascan -c '/bin/sh -c "'/usr/local/jdk1.7.0_80/jre/bin/java' -XshowSettings:properties -version'"]

Principle of least privilege

Some users choose to run the Snow agent and scanners under a non-administrative user account. In this scenario, Java security levels do not affect execution behavior. All Java binaries are executed as the scanning user.

In this case:

• No Java binaries are treated differently
• The ImpersonationUser setting is never used
• The default javascan account does not need to exist on the operating system