1

I have a Java Application which generates a temporary JNA folder and a temporary DLL file to the following location in the users' profile:

%OSDRIVE%\Users\ABC-<SOME-USER-ID>\AppData\Local\Temp\jna--881477353\jna7513918229606912988.dll

(the JNA folder and file names contain random numbers as suffix and with prefix "jna--" , "jna" respectively)

The JNA DLL file "Path" needs to be made an exception in Application Control Policies, specifically in AppLocker -> DLL Rules -> [Users] -> Exceptions in order for the Java app to function properly. At the moment, it is blocked by the AppLocker, however, if I add this path to the AppLocker, it will work for the current user.

Now, this is achievable for 1 user, but I have many users with the prefix as "ABC-" and the suffix "SOME-USER-ID" contains a random string with numbers and letters, i.e. many users who have prefix "ABC-" should be able to use this application without the need for manually adding every users' profile path into the AppLocker configuration.

Is there a way I can "Wildcard" this path into the AppLocker configuration? For example, something like this:

%OSDRIVE%\Users\ABC-<WILDCARD>\AppData\Local\Temp\jna--<WILDCARD>\jna<WILDCARD>.dll

or even:

%OSDRIVE%\Users\ABC-<WILDCARD>\AppData\Local\Temp\jna--<WILDCARD>\*

Is there a realistic way of achieving this via Wildcards? I do not wish to use "*" inside the path because it will then allow ALL users to be exempted from the AppLocker settings.

Any help is appreciated.

Thanks in advance!

user136819
  • 205
  • 7
  • 21

1 Answers1

1

Based on the available documentation I could find, it appears that a wildcard (*) character is only supported in AppLocker at the beginning or end of a path, but not in the middle. So your proposed solution is impossible.

However, rather than using a wildcard in the path for AppLocker, you can pre-extract the JNA native library to a known location for all users. This is a relatively common need for security purposes (exactly your intent), sometimes related to temp directory access permissions or sometimes related to signing binaries.

From the JNA API Overview Loading JNA:

JNA includes a small, platform-specific shared library which enables all native access. When the Native class is first accessed, JNA will first attempt to load this library from the directories specified in jna.boot.library.path. If that fails and jna.nosys=false is set, it will fall back to loading from the system library paths. Finally it will attempt to extract the stub library from from the JNA jar file, and load it.

This gives you two options to avoid the randomly-named temporary file. Copy it to:

  • a directory of your choice, and either pass -Djna.boot.library.path=C:\your\path on the java command line, or before loading JNA call System.setProperty("jna.boot.library.path", "C:\your\path") in your program.
  • a system directory on the PATH, e.g. System32, and set jna.nosys=false. (You can also set jna.nounpack=true to prevent the temp file unpacking.)

In addition, the JNA native library will be in a subdirectory of the Java temporary directory specified by the java.io.tmpdir system property. See this SO question: Environment variable to control java.io.tmpdir?

Answers to that question include using the _JAVA_OPTIONS environment variable as a possible means to change the tmpdir even if you're running an executable rather than Java command line.

Daniel Widdis
  • 8,424
  • 13
  • 41
  • 63
  • Thanks for answering @Daniel. This may have been the solution, however, the Java Application is pre-built and I cannot modify the source code (I should have mentioned this part in the original question, my bad). And I don't see any "*.properties" files in the application folder to set the Path variables either. Is there still a way to go with the Wildcard approach for the AppLocker? (this would eventually also save us time) – user136819 Dec 13 '22 at 13:59
  • 1
    @user136819 Based on [the docs](https://github.com/isbrahm/windows-itpro-docs/blob/2a1630822c9833417543a87d959638eab5f21c4f/windows/security/threat-protection/windows-defender-application-control/select-types-of-rules-to-create.md) you can only use a wildcard at the beginning or end of the path, not in the middle. – Daniel Widdis Dec 13 '22 at 18:00
  • I see. Well, it was worth a shot with the AppLocker. But I saw something like "jna.tmpdir" and "java.io.tmpdir" on this question here: https://stackoverflow.com/questions/59763859/how-to-override-jna-tmpdir-and-java-io-tmpdir-properties-in-testcontainers ... Anyway I can override these 2 props? (this may even help the original poster of that question!) – user136819 Dec 14 '22 at 20:04
  • @user136819 Those would work: Those properties just override the location that you extract the DLL to. So you could set those to always extract to `C:\your\custom\path` where you've added `C:\your\custom\path\*` to AppLocker. You'll still get a randomly named jna dll in that directory. But they still require a "Java System Property" to be set by whoever is starting the jvm using a `-D` switch on the command line. If you have any control over the JVM when starting this program you can do that. If it's a compiled executable you can't and need to ask the authors to enable it. – Daniel Widdis Dec 14 '22 at 22:09
  • @user136819 in theory you could change the environment variable `%TEMP%` to an allowed location and you would know it would be under a JNA path there. I'm not sure, but it's possible that an AppLocker path `%TEMP%\jna*` might work? – Daniel Widdis Dec 14 '22 at 22:12
  • Unfortunately, the AppLocker reconfiguration isn't an option with `%TEMP%` anymore due to hardening of the server and we aren't allowed to change this. But we are thinking of going with the `-D` switch via command line. Currently, we pass something like this in command line to open the Java app: `"C:\\java\bin\javaw.exe" -classpath "C:\\.exe;commons-logging-1.2.jar;httpclient-4.5.10.jar;httpcore-4.4.12.jar" com.x.x.java.ui.JAppLauncher` Where can I include the `-D` switch path in the above command? (i.e. this part: `-Djna.boot.library.path=C:\your\path`) – user136819 Dec 19 '22 at 10:25
  • An additional comment: is there any way a custom JAR file will be able to override the `jna.tmpdir` and `java.io.tmpdir`? Can we be able to create one or does it exist online already? – user136819 Dec 19 '22 at 12:38
  • @user136819 how are you starting the program? If you're executing via Java you just add those as command line arguments. – Daniel Widdis Dec 19 '22 at 17:59
  • 1
    so basically the program can be started from the command line, but we were exploring ways to just use the `.exe` executable instead of passing a long command line argument. Ultimately, we ended up simply using the command line thing and finally, we were able to solve our issue with this command: `"C:\\java\bin\javaw.exe" -Djava.io.tmpdir="C:\\temp" -classpath "C:\\.exe;commons-logging-1.2.jar;httpclient-4.5.10.jar;httpcore-4.4.12.jar" com.x.x.java.ui.JAppLauncher` . Now, the DLL is generated into the custom path! ;) Thank you for your hints! – user136819 Dec 23 '22 at 18:17
  • @user136819 a little late but I just realized the `_JAVA_OPTIONS` environment vairable migh thave worked with the .exe: `export _JAVA_OPTIONS=-Djava.io.tmpdir=/new/tmp/dir` – Daniel Widdis Dec 23 '22 at 19:46