Blocking Oracle Java

As a follow-up to my previous post on removing Oracle Java, it’s possible that Mac admins may be requested to block Oracle Java in place of removing it. This may be challenging, but possible with the right information and tools. For more details, please see below the jump.

Removing Oracle Java from macOS

As of January 23, 2023, Oracle made a change to how they’ve licensed Oracle’s Java (which is a separate license from the ones used for open source Java distributions like OpenJDK.) The new license terms are described here in Oracle’s FAQ, but to summarize the main difference between the old licensing and the current licensing is that Oracle introduced a new employee-based metric.

• Old license: License costs were based on how many employees your company has which used Oracle’s Java.
• Current license: License costs are based on how many employees your company has.

See the difference? Previously, if your company had 1000 employees and 2 used Oracle’s Java for purposes which required payment under the old license, the company paid for 2 licenses. Under the current license, if your company has 1000 employees and 2 use Oracle’s Java, Oracle may say that now the company needs to pay for 1000 licenses.

There’s more to it and I am not the person to turn to when needing explanation of complex legal and financial questions, but the operational consequence for Mac admins is that companies which had previously been OK with Oracle Java being installed on their Macs may now be coming to their Mac admins, asking how Oracle Java can be removed and kept off.

To assist with this, I’ve written a script which should remove Oracle Java JREs and JDKs on macOS. For more details, please see below the jump.

Remediating Log4Shell on Jamf Pro

On Thursday, December 9th 2021, a vulnerability was discovered in the popular Java logging library (log4j) which allowed for Remote Code Execution (RCE) by logging a certain string. This vulnerability has been dubbed Log4shell:

https://twitter.com/GossiTheDog/status/1469252309058306051?s=20

How bad is this? I’ll let the below video of a Minecraft server being changed into a DOOM server via this vulnerability speak to how a remote attacker could use Log4shell to give you a bad day:

so fixing log4shell is great and all, but.. wouldn't it be ✨ amazing ✨ if we all just promised to be nice and instead use this power to make vanilla minecraft doom server 🤔 pic.twitter.com/tCaUCG1dqg

— Gegy (@gegybeans) December 11, 2021

It’s bad. It’s hard to overstate how bad. My colleague Ben Toms has a good write up on this issue here:

https://macmule.com/2021/12/11/jamf-pro-and-log4shell-cve-2021-44228

To address this vulnerability, the log4j folks have released an updated version of the logging tool which is not vulnerable. It’s log4j 2.1.5 and is available for download via the link below:

https://logging.apache.org/log4j/2.x/download.html

---

Update 12-15-2021:

Log4j 2.16.0 has been released to address remaining vulnerabilities in 2.15.0 by completely disabling Java Naming and Directory Interface (JNDI) lookups by default. It can be downloaded via the link below:

https://logging.apache.org/log4j/2.x/download.html

Insecure JNDI lookups are what enable the Log4Shell vulnerability, so having JNDI disabled by default in addition to 2.16.0’s removal of its message lookups functionality fixes the vulnerability .

Jamf has stated that they have evaluated CVE-2021-45046, which prompted the release of 2.16.0, and the results of their evaluation are that it does not appear that the conditions which are covered by CVE-2021-45046 should occur with Jamf’s products.

As of December 15th 2021, Jamf has not provided guidance on updating from log4j 2.15.0 to log4j 2.16.0

---

The files to download are one of the following two:

• Apache log4j 2 binary (tar.gz)
• Apache log4j 2 binary (zip)

Both have the same contents, the main difference is how they are compressed. Once downloaded and uncompressed, you should have the following files:

	LICENSE.txt
	NOTICE.txt
	RELEASE-NOTES.md
	log4j-1.2-api-2.15.0-javadoc.jar
	log4j-1.2-api-2.15.0-sources.jar
	log4j-1.2-api-2.15.0.jar
	log4j-api-2.15.0-javadoc.jar
	log4j-api-2.15.0-sources.jar
	log4j-api-2.15.0.jar
	log4j-appserver-2.15.0-javadoc.jar
	log4j-appserver-2.15.0-sources.jar
	log4j-appserver-2.15.0.jar
	log4j-cassandra-2.15.0-javadoc.jar
	log4j-cassandra-2.15.0-sources.jar
	log4j-cassandra-2.15.0.jar
	log4j-core-2.15.0-javadoc.jar
	log4j-core-2.15.0-sources.jar
	log4j-core-2.15.0-tests.jar
	log4j-core-2.15.0.jar
	log4j-couchdb-2.15.0-javadoc.jar
	log4j-couchdb-2.15.0-sources.jar
	log4j-couchdb-2.15.0.jar
	log4j-docker-2.15.0-javadoc.jar
	log4j-docker-2.15.0-sources.jar
	log4j-docker-2.15.0.jar
	log4j-flume-ng-2.15.0-javadoc.jar
	log4j-flume-ng-2.15.0-sources.jar
	log4j-flume-ng-2.15.0.jar
	log4j-iostreams-2.15.0-javadoc.jar
	log4j-iostreams-2.15.0-sources.jar
	log4j-iostreams-2.15.0.jar
	log4j-jcl-2.15.0-javadoc.jar
	log4j-jcl-2.15.0-sources.jar
	log4j-jcl-2.15.0.jar
	log4j-jdbc-dbcp2-2.15.0-javadoc.jar
	log4j-jdbc-dbcp2-2.15.0-sources.jar
	log4j-jdbc-dbcp2-2.15.0.jar
	log4j-jmx-gui-2.15.0-javadoc.jar
	log4j-jmx-gui-2.15.0-sources.jar
	log4j-jmx-gui-2.15.0.jar
	log4j-jpa-2.15.0-javadoc.jar
	log4j-jpa-2.15.0-sources.jar
	log4j-jpa-2.15.0.jar
	log4j-jul-2.15.0-javadoc.jar
	log4j-jul-2.15.0-sources.jar
	log4j-jul-2.15.0.jar
	log4j-liquibase-2.15.0-javadoc.jar
	log4j-liquibase-2.15.0-sources.jar
	log4j-liquibase-2.15.0.jar
	log4j-mongodb3-2.15.0-javadoc.jar
	log4j-mongodb3-2.15.0-sources.jar
	log4j-mongodb3-2.15.0.jar
	log4j-mongodb4-2.15.0-javadoc.jar
	log4j-mongodb4-2.15.0-sources.jar
	log4j-mongodb4-2.15.0.jar
	log4j-slf4j-impl-2.15.0-javadoc.jar
	log4j-slf4j-impl-2.15.0-sources.jar
	log4j-slf4j-impl-2.15.0.jar
	log4j-slf4j18-impl-2.15.0-javadoc.jar
	log4j-slf4j18-impl-2.15.0-sources.jar
	log4j-slf4j18-impl-2.15.0.jar
	log4j-spring-boot-2.15.0-javadoc.jar
	log4j-spring-boot-2.15.0-sources.jar
	log4j-spring-boot-2.15.0.jar
	log4j-spring-cloud-config-client-2.15.0-javadoc.jar
	log4j-spring-cloud-config-client-2.15.0-sources.jar
	log4j-spring-cloud-config-client-2.15.0.jar
	log4j-taglib-2.15.0-javadoc.jar
	log4j-taglib-2.15.0-sources.jar
	log4j-taglib-2.15.0.jar
	log4j-to-slf4j-2.15.0-javadoc.jar
	log4j-to-slf4j-2.15.0-sources.jar
	log4j-to-slf4j-2.15.0.jar
	log4j-web-2.15.0-javadoc.jar
	log4j-web-2.15.0-sources.jar
	log4j-web-2.15.0.jar

view raw

output.txt

hosted with ❤ by GitHub

The ones relevant to Jamf Pro are the following:

• log4j-1.2-api-2.15.0.jar
• log4j-api-2.15.0.jar
• log4j-core-2.15.0.jar
• log4j-slf4j-impl-2.15.0.jar

For more details, please see below the jump.

Installer package identifiers and the mystery of the missing Java 11 files

As part of developing new AutoPkg recipes to support SapMachine‘s new Long Term Support (LTS) distribution for Java 17, I ran into a curious problem when testing. When I ran the SapMachine Java 17 LTS installer that was being generated by AutoPkg, I was seeing the following behavior:

• SapMachine Java 17 LTS is installed by itself – no problem
• SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed – no problem
• SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed – SapMachine Java 11 LTS is removed, only SapMachine Java 17 LTS is installed now.

I double-checked the preinstall script for the SapMachine Java 17 LTS installer. It is supposed to remove an existing SapMachine Java 17 LTS installation with the same version info, but it should not have also been removing SapMachine Java 11 LTS. After a re-review of the script and additional testing, I was able to rule out the script as the problem. But what was causing this behavior? Also, why was it happening in this order?

• SapMachine Java 11 LTS installed, then SapMachine Java 17 LTS is installed

But not this order?

• SapMachine Java 17 LTS installed, then SapMachine Java 11 LTS is installed

The answer was in how the package’s package identifier was set up. For more details, please see below the jump.

Jamf Pro deprecating the ability to issue a Tomcat certificate from the Jamf Pro built-in certificate authority

As part of the release of Jamf Pro 10.30, the following entry was added to the Deprecations section of the Jamf Pro Release Notes:

Functionality to issue the Tomcat SSL/TLS certificate from Jamf Pro’s built-in certificate authority — Jamf Pro’s functionality to issue the Tomcat SSL/TLS certificate from the JSS built-in certificate authority (CA) will be discontinued in a future release of Jamf Pro. The release version for this change has not been determined.

Before this change occurs, it is recommended that all on-premise Jamf Pro instances leveraging this functionality switch to a publicly trusted third-party CA to issue the Tomcat SSL/TLS certificate. This will prevent the potential loss of MDM communication from Jamf Pro to enrolled devices.

If needed, a Tomcat SSL/TLS server certificate for Jamf Pro may be issued from an internal certificate authority. The JSS built-in CA will maintain its current ability to manually issue server certificates to other servers.

For shops which use Jamf Pro’s built-in certificate authority to create the SSL certificate used by the Tomcat web application, this means that at some point in the near(ish) future, you will need to plan to use a certificate for your Jamf Pro server which is no longer being issued by your Jamf Pro server’s built-in certificate authority.

For more details, please see below the jump.

Identifying vendors of installed Java JDKs using Jamf Pro

Since Oracle’s license change for Java 11 and later took effect in October 2018, where Oracle announced that they would now be charging for the production use of Oracle’s Java 11 and later, the number of open source (and free) OpenJDK distributions has increased dramatically.

Before the license change, most Mac admins would only install Oracle Java on those Macs which needed Java. Now, the list of available vendors has broadened to include the following:

• AdoptOpenJDK
• Amazon
• Azul
• OpenJDK
• Oracle
• SAP

Note: There may be even more OpenJDK distributions available for macOS, but these are the ones I know of.

To help Jamf Pro admins keep track of which vendors’ Java distributions are installed on their Macs, I’ve written a Jamf Pro Extension Attribute to help identify them. For more details, please see below the jump.

Packaging SAP GUI for macOS with Java 11 support

A while back, I wrote a post on building a SAP GUI installer for macOS, where SAP GUI needed to have Oracle’s Java 8 JDK as a pre-requisite. Since then Oracle has made an announcement that the use of Oracle’s Java 11 JDK is no longer free if you’re using it for production work.

One of the consequences of that decision by Oracle is that SAP GUI 7.50 rev 5 is the first version of SAP GUI to support Java 11. However, the SAP GUI developers are now recommending the use of OpenJDK 11 in place of Oracle’s Java JDK 11. More specifically, the SAP GUI folks are recommending the use of SAP’s own SapMachine Java JDK 11 release.

Meanwhile, a Java library named JavaFX used by SAP GUI is no longer being bundled as part of Java 11. Instead, JavaFX has been split off into its own open source project called OpenJFX and is now a separate install.

What do SapMachine JDK 11 and JavaFX have in common? Among other things, neither have a native installer for macOS. Instead, each is distributed via compressed files.

Installation is performed by uncompressing into the following directory on macOS:

/Library/Java/JavaVirtualMachines

That said, SAP GUI also still works with Oracle’s Java JDK 8 as of the release of SAP GUI 7.50 rev 5. JavaFX is bundled with Java JDK 8, so installing Oracle’s Java JDK 8 handles both the Java and JavaFX requirements.

With all the changes, how should SAP GUI now be packaged for installation? Without question, the main challenge for deployment here is going to be the Java component. In my testing, which was limited to “Launch SAP GUI and see if it runs”, I found SAP GUI 7.50 rev 5 is able to run on the following Java releases:

• Oracle Java JDK 8 Update 191
• Oracle Java JDK 11.0.1
• OpenJDK 11.0.1
• SapMachine JDK 11.0.1.13

If using any Java 11 release, OpenJFX will need to be installed for SAP GUI to successfully run.

With this in mind, it’s possible to build a package that does the following:

1. Detects if Java is installed
2. Detects if JavaFX is installed
3. If Java is not installed, install the latest release of SapMachine JDK.
4. If JavaFX is not installed, install the latest release of OpenJFX.
5. Verifies that both Java and JavaFX are installed.
6. If both Java and JavaFX are installed, install SAP GUI

For more details, please see below the jump.

Oracle Java JDK, OpenJDK, Java 11 and macOS

With Java 8 approaching the end of its lifecycle, Oracle has made some changes to the Oracle JDK license that will affect Java 11’s JDK. As of Oracle Java JDK 8, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping
• Production

As of Oracle Java JDK 11, you can use the JDK for free in the following circumstances:

• Development
• Testing
• Prototyping

Notice that Production has dropped off the list? If you use Oracle Java JDK 11 for production use, Oracle is now expecting payment. For the complete details, please see the license agreement (relevant sections highlighted below):

If you don’t want to or can’t pay Oracle, what are the available options?

1. Keep using Oracle Java JDK 8

Oracle will continue to provide updates for Java 8 until January 2019, so a short-term solution is to keep using JDK 8 until support ends. This is only a short term solution however. If you want to continue using Java 8 past January 2019, you may need to start paying Oracle in order to get access to continuing Java 8 support.

2. Migrate from Oracle Java JDK to OpenJDK

In addition to its commercial offering, Oracle has an open-source Java available named OpenJDK. As of Java 11, Oracle will be providing functionally identical JDK builds to both the commercially licensed Oracle JDK and the open-source OpenJDK. For more details, please see below the jump:

Building an SAP GUI installer for macOS

Since I’ve started working for my current employer, my colleagues and I have occasionally received the following question from various Mac admins:

“I’m using SAP in my environment. How do I deploy the Mac software for SAP?”

When we’ve followed up for more details, the “Mac software for SAP” usually means the SAP GUI software. SAP GUI comes in two flavors:

• SAP GUI for Windows
• SAP GUI for Java

SAP GUI for Java supports the following operating systems:

• openSUSE
• Fedora
• macOS
• Microsoft Windows
• AIX
• Ubuntu

The SAP GUI for Java is what’s available for macOS, so how to get it and deploy it? For more details, please see below the jump.

Automating Jamf Infrastructure Manager setups on Red Hat Enterprise Linux

As part of a project, I needed to build an automated setup process for a Jamf Infrastructure Manager (JIM). Thanks to the help of some folks at Jamf, I have a process which runs non-interactively and which does the following on Red Hat Enterprise Linux 7.x:

1. Installs the JIM software
2. Enrolls the JIM with a Jamf Pro server

For more details, please see below the jump.