Oracle Java 9 JDK and JRE installation scripts for macOS

Oracle has started to release Java 9 for macOS, so I’m posting a couple of scripts to download and install the following:

Oracle Java 9 JRE
Oracle Java 9 JDK

Oracle has been releasing two separate versions of Java 8 simultaneously and may do the same for Java 9, so these Java 9-focused scripts are designed to allow the user to set which version they want to install: the CPU release or the PSU release.

The difference between CPU and PSU releases is as follows:

  • Critical Patch Update (CPU): contains both fixes to security vulnerabilities and critical bug fixes.
  • Patch Set Update (PSU): contains all the fixes in the corresponding CPU, plus additional fixes to non-critical problems.

For more details on the differences between CPU and PSU updates, please see the link below:

http://www.oracle.com/technetwork/java/javase/cpu-psu-explained-2331472.html

For more information, please see below the jump.

The scripts are available on GitHub via the links below:

Oracle Java 9 JDK: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_oracle_java_jdk_9
Oracle Java 9 JRE: https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/install_latest_oracle_java_jre_9

The scripts are also available as payload-free packages, compressed and stored as .zip files in the payload_free_package directory available via the links above.

Oracle Java 9 JDK script:

The script below will download a disk image containing the latest version of the Java 9 JDK from Oracle and install the JDK using the installer package stored inside the downloaded disk image.

How the script works:

  1. Verifies that the Mac is running a Java 9-compatible operating system
  2. Uses curl to download a disk image containing the latest Java 9 JDK installer from Oracle’s web site
  3. Renames the downloaded disk image to java_nine_jdk.dmg and stores it in the /tmp directory.
  4. Mounts the disk image silently in the /tmp directory. The mounted disk image will not be visible to any logged-in user.
  5. Installs the latest Java 9 JDK using the installer package stored inside the disk image.
  6. After installation, unmounts the disk image and removes it from the Mac in question.

Oracle Java 9 JRE script:

The script below will download a disk image containing the latest version of the Java 9 JRE from Oracle and install the JRE using the installer package stored inside the downloaded disk image.

How the script works:

  1. Verifies that the Mac is running a Java 9-compatible operating system
  2. Uses curl to download a disk image containing the latest Java 9 JRE installer from Oracle’s web site
  3. Renames the downloaded disk image to java_nine_jre.dmg and stores it in the /tmp directory.
  4. Mounts the disk image silently in the /tmp directory. The mounted disk image will not be visible to any logged-in user.
  5. Installs the latest Java 9 JRE using the installer package stored inside the disk image.
  6. After installation, unmounts the disk image and removes it from the Mac in question.

FileVault recovery key redirection profile changes in macOS High Sierra

For macOS Sierra and earlier, Apple had a dedicated FileVault Recovery Key Redirection profile payload for FileVault recovery key redirection. This profile was designed to work with a mobile device management (MDM) server, to allow the MDM server to act as a recovery key escrow service and store FileVault personal recovery keys.

Screen Shot 2018 01 15 at 12 40 23 PM

Note: Jamf Pro will be used as the example MDM server in this post. However, similar functionality is available in other MDM services.

On macOS High Sierra, this FileVault Recovery Key Redirection profile payload no longer works. In its place, Apple has added new Enable Escrow Personal Recovery Key settings to the FileVault section of the existing Security profile payload.

Screen Shot 2018 01 15 at 12 44 56 PM

Adding the recovery key redirection to the Security payload may cause issues in some environments, as the Security profile payload has other settings which those environments may prefer to manage separately, or not manage at all.

For those who prefer to manage FileVault recovery key redirection separately from the other settings managed by the Security payload, it is possible to create a profile (with some manual editing) which only manages FileVault recovery key redirection. For more details, see below the jump.

The first thing to do is to create a new profile (which should not be assigned to any Macs) and configure the Security profile payload with the desired recovery settings on your MDM server.

Screen Shot 2018 01 15 at 12 44 57 PM

Once the profile is configured as desired, download a copy of the profile to your workstation. After downloading, the profile can be edited to include only those settings which manage the FileVault recovery key redirection. To help with figuring out the appropriate settings, I have a sample profile available below.

Note: As currently set up, the sample profile doesn’t redirect recovery keys. It needs the relevant payload content (specifically the FileVault2Comm.cer certificate payload) from the Security profile created by your own MDM server:

Once the profile has been edited and all settings have been verified:

  1. Upload the profile to your MDM server
  2. Deploy the profile to a test Mac
  3. Rotate the FileVault personal recovery key on the test Mac to verify that redirection is working as desired.

Screen Shot 2018 01 15 at 1 15 58 PM

Screen Shot 2018 01 15 at 1 18 26 PM

To make sure that the MDM server does not try to alter the edited FileVault recovery key redirection profile, I recommend signing the profile.

Screen Shot 2018 01 15 at 1 15 59 PM

Signing the profile encrypts it, which prevents the MDM from changing the profile’s contents. The MDM server can now serve out the redirection profile, but will not be able to edit it or change it in any way.

Secure Enclave, Mac SSD hardware encryption and the future of FileVault

The iMac Pro introduced a number of new features, but one that may have been little noticed is the introduction of hardware encryption for the iMac Pro’s SSD storage. Apple references the hardware encryption on the iMac Pro page this way:

T2 also makes iMac Pro even more secure, thanks to a Secure Enclave coprocessor that provides the foundation for new encrypted storage and secure boot capabilities. The data on your SSD is encrypted using dedicated AES hardware with no effect on the SSD’s performance, while keeping the Intel Xeon processor free for your compute tasks.

Screen Shot 2018 01 07 at 9 32 21 PM

This hardware encryption means that, even if FileVault is not enabled, the data stored on the iMac Pro’s SSD storage is encrypted. What’s more, the key to unlock the encryption is stored in the iMac Pro’s Secure Enclave and never leaves the machine. Physically remove the SSD storage from the iMac Pro and you won’t be able to access any data stored on the SSD, even if you have an otherwise identical iMac Pro available.

For those with knowledge of how Apple protects data stored on iOS devices, this should sound familiar. The main difference between the iOS and macOS implementation at this point appears to be that macOS does not have the equivalent passcode lock screen.

Iphone7 ios11 passcode lock screen

Instead, the needed encryption key to unlock the hardware encryption is automatically provided by the Secure Enclave when the iMac Pro boots. This behavior is just like that seen on an iOS device where a passcode has not been enabled.

This is referenced when you run the following command on an iMac Pro:

diskutil apfs list

On an iMac Pro where FileVault is not enabled, FileVault is shown with the following status:

FileVault: No (Encrypted at rest)

Screen Shot 2018 01 07 at 9 28 23 PM

This recognizes that encryption is available, but that the encryption only provides protection when the data is at rest. “Data at rest” in this context should be understood to mean when the Secure Enclave has not provided the needed encryption unlock key, which would be the case in either of the following scenarios:

  1. The iMac Pro is off.
  2. The SSD storage has been removed from the iMac Pro.

For more, please see below the jump.

So what does this hardware encryption mean for FileVault on Apple File System? Is it no longer needed? Will Apple be implementing a passcode lock, like they have on iOS? Will hardware encryption allow FileVault to be enabled in seconds, rather than hours?

I don’t have any inside knowledge, so treat what I’m about to say with the appropriate skepticism. It’s speculation, pure and simple.

That said, I don’t think that Apple will be mapping the iOS passcode experience directly onto macOS. The reason I say that is iOS’s encryption model incorporates an assumption that iOS is not a multi-user OS. That’s where FileVault encryption on Apple File System comes in. It provides the following:

  1. The ability to support multiple user accounts.
  2. An additional encryption layer, providing even more protection for the data stored on the iMac Pro’s SSD storage.

Because of this, I see FileVault on Apple File System staying around for at least the next version of macOS while Apple works out the necessary support for providing an instant-on encryption solution like on iOS, while being able to provide the multiple-user support needed on macOS.

That said, I believe that this transition will be a short one of only one to two years. FileVault on Apple File System will then become a feature needed mostly on Mac hardware which lacks a Secure Enclave. Encryption on Macs equipped with Secure Enclave will change, from something that Mac admins will need to enable and monitor, to something which is Just On and which Just Works.

Hat tip to Tim Perfitt for providing technical assistance with the content in this post. If you’re interested in the iMac Pro’s other changes, please check out Tim’s post on Secure Boot and the iMac Pro.

Setting your Mac to receive macOS beta updates using seedutil

As part of a discussion of how to build test VMs, a colleague mentioned how they were using the seedutil tool to help configure Macs to access Apple’s beta updates. I hadn’t run across this tool before, so I decided to do some research and see if I could make it work for my own testing needs. For more details, see below the jump.

seedutil is available at the following location in macOS 10.13.2:

/System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/seedutil

There is no manpage for it, but if you call the seedutil tool by itself it will display the following options:

Here’s how the following seedutil options work on macOS 10.13.2:

seedutil enroll: Sets up the Mac to use one of three beta update feeds from Apple’s Software Update servers.

CustomerSeedAppleSeed beta OS releases
DeveloperSeedApple Developer Connection beta OS releases
PublicSeedmacOS public beta OS releases

Screen Shot 2018 01 05 at 9 38 22 PM

These feeds are referenced from the following file:

/System/Library/PrivateFrameworks/Seeding.framework/Versions/A/Resources/SeedCatalogs.plist

seedutil unenroll: Removes the current beta feed from the Mac and sets it to use the regular macOS updates.

Screen Shot 2018 01 05 at 10 36 34 PM

seedutil current: Displays information about the beta feed which the Mac is using.

Screen Shot 2018 01 05 at 10 25 10 PM

seedutil fixup: Repairs problems with the currently-enrolled beta feed.

Screen Shot 2018 01 05 at 10 34 36 PM

I was not able to discover what seedutil‘s migrate function does. If any readers know, please let me know in the comments.

If you run seedutil enroll and specify a beta update feed, the next time you run Software Update you should see the latest beta update appear as an available update option.

Screen Shot 2018 01 05 at 10 38 28 PM

Screen Shot 2018 01 05 at 9 36 22 PM

One reason why this tool is particularly interesting to me is that it can be used to install the latest macOS beta software onto an otherwise-unconfigured test Mac or test macOS VM. As an example of this, I’ve written the following script:

I’ve created a payload-free package from the script and then added it to a DeployStudio workflow. This workflow does the following:

1. Allows you to select a drive

Screen Shot 2018 01 05 at 9 34 49 PM

2. Installs the payload-free package, which uses seedutil to configure the Mac to use the selected beta OS feed.

Screen Shot 2018 01 05 at 9 35 27 PM

3. Runs Software Update.

Screen Shot 2018 01 05 at 9 35 35 PM

Once the workflow has completed its run and rebooted, the following actions take place at first boot:

A. The Mac is configured to use the selected beta feed
B. Apple’s softwareupdate tool checks for, downloads and installs all relevant updates, including the latest beta OS updates.
C. Following the installation of all available updates, the Mac restarts.

Screen Shot 2018 01 05 at 9 58 52 PM

At the end of the process, you should have a factory-fresh test Mac or VM which already has the latest macOS beta software installed.

Note: This workflow is not dependent on DeployStudio, the general idea should also be replicable using other tools such as Imagr.

Decrypting an APFS encrypted volume using diskutil on macOS 10.13.2

Apple has made changes as of macOS 10.13.2 to the way you can turn off APFS encryption when using the diskutil apfs decryptVolume command.

On macOS 10.13.0 and 10.13.1, an APFS encrypted volume could be decrypted using the following procedure:

  1. Identify the relevant encrypted APFS volume
  2. Unlock the encrypted APFS volume
  3. Decrypt the encrypted APFS volume

Once the drive has been unlocked, you could then decrypt the APFS volume using the command shown below:

diskutil apfs decryptVolume /dev/apfs_volume_id_here

As long as you were using root or admin privileges to run the command, no additional authentication was required to decrypt an unlocked encrypted volume.

Screen Shot 2017 11 03 at 11 02 23 PM

However, the diskutil apfs decryptVolume command has been updated on macOS 10.13.2 to require additional authentication:

In order to decrypt using a user account’s password or personal recovery key (PRK), it is necessary to specify the following:

  1. The relevant user UUID
  2. The relevant account password or the PRK.

Note: As of macOS 10.13.2, it is not possible to decrypt an encrypted APFS volume using an institutional recovery key (IRK). You can unlock an encrypted APFS volume using an IRK, but diskutil apfs decryptVolume does not include functionality for using an IRK to authenticate the decryption of an encrypted APFS volume.

For more details, please see below the jump.

If you are planning to use a user account’s password to decrypt, you will first need to correctly identify the relevant encrypted APFS volume and which UUID you want to use.

In this case, we’ll be using the following APFS volume identifier:

/dev/disk1s1

Screen Shot 2017 10 16 at 4 34 25 PM

 

The other assumption is that the encrypted APFS volume has been unlocked and is ready for decryption.

If you are booted from the encrypted drive, you can get the UUID of a user account by running the command shown below and matching which UUID belongs to the account you want to use.

fdesetup list

Fdesetup list apfs

 

If you are not booted from the encrypted drive, there is another way to get the UUID by running the command shown below and looking at the entries listed as Local Open Directory User. However, this method will not display the account name and may require some guesswork if there is more than one FileVault enabled account enabled.

diskutil apfs listcryptousers /dev/apfs_volume_id_goes_here

Diskutil apfs listcryptousers dev disk1s1

 

 

Once you have access to the UUID and password of one of the enabled accounts on the encrypted APFS volume, you can unlock using the command below. You will be prompted to provide the password:

diskutil apfs decryptVolume /dev/apfs_volume_id_goes_here -user uuid_goes_here

Diskutil apfs decryptVolume dev disk1s1 user account UUID decrypting

If you want to use the PRK, the PRK has its own UUID which only appears if you run the following command:

diskutil apfs listcryptousers /dev/apfs_volume_id_goes_here

In this case, use the UUID associated with the Personal Recovery User entry.

Diskutil apfs listcryptousers dev disk1s1 personal recovery key UUID

If you have access to the PRK associated with the encrypted APFS volume, you can decrypt using the command below. You will need to provide the relevant UUID and the alphanumeric personal recovery key as part of the command.

diskutil apfs decryptVolume /dev/apfs_volume_id_goes_here -user uuid_goes_here -passphrase personal_recovery_key_goes_here

Diskutil apfs decryptVolume dev disk1s1 personal recovery key UUID and passphrase decrypting

 

To show the process of decrypting an unlocked encrypted APFS volume while using a personal recovery key, please see below for a video:

Creating local user accounts with pycreateuserpkg

As part of setting up new Macs, you may want to add one or more local user accounts with a pre-determined password to those Macs. The reasons for this may include the following:

  • Setting up a local administrator account
  • Setting up a “loaner” user account for a pool of loaner laptops
  • Setting up a local user account that automatically logs at startup for a library kiosk
  • Setting up a generic “student” account for use in a school’s computer lab

Previously, it was possible to use the venerable CreateUserPkg utility to accomplish this goal, but the password scheme used by CreateUserPkg stopped working on macOS High Sierra. An alternative tool which works on macOS High Sierra is pycreateuserpkg, a Python script written by Greg Neagle which generates packages that create local user accounts when installed. For more information, see below the jump.

Using pycreateuserpkg:

1. Download pycreateuserpkg from GitHub using the link below:

https://github.com/gregneagle/pycreateuserpkg

2. Decide on the settings you want for the new user account, using the options available below:

As an example, let’s create an installer package which installs a local user account with the following characteristics:

Account’s shortname: kiosk
Account’s displayed name: Kiosk
UID: 604
Account shell: /bin/bash
Account should have admin rights: No
Account should auto-login: Yes

Since we also need to provide version and identifier information for the installer package, we’ll use the following characteristics:

Version number: 1.0
Package identifier: com.github.kiosk_user_setup

To create the installer package which installs the previously-defined local account, make sure you have a copy of pycreateuserpkg available, then use the command shown below:

/path/to/createuserpkg --name="kiosk" --uid=604 --fullname="Kiosk" --shell="/bin/bash" --version=1.0 --identifier="com.github.kiosk_user_setup" "Create Kiosk User Account.pkg" --autologin

Screen Shot 2017 12 23 at 9 24 30 PM

 

Since we have not defined what the account’s password will be as part of the command above, we will be prompted to enter the password then enter it again to verify:

Screen Shot 2017 12 23 at 9 26 05 PM

 

Screen Shot 2017 12 23 at 9 26 21 PM

 

That should generate a new installer package named Create Kiosk User Account.pkg.

Screen Shot 2017 12 23 at 9 27 52 PM 

Testing pycreateuserpkg-generated installers

Once the package has been built, test it by taking the pycreateuserpkg-generated installer package and install it on a Mac which does not have the local account set up on it. The end result should be that the local account is set up on the Mac and configured with the desired settings and account rights.

Screen Shot 2017 12 23 at 9 32 12 PM

Screen Shot 2017 12 23 at 9 32 16 PM

 

To give some additional examples, let’s create a local administrator account with the following characteristics:

Account’s shortname: admin
Account’s displayed name: Administrator
UID: 600
Account shell: /bin/bash
Account should have admin rights: Yes
Account should auto-login: No

Since we also need to provide version and identifier information for the installer package, we’ll use the following characteristics:

Version number: 1.0
Package identifier: com.github.admin_user_setup

To create the installer package which installs the previously-defined local account, make sure you have a copy of pycreateuserpkg available, then use the command shown below:

/path/to/createuserpkg --name="admin" --uid=600 --fullname="Administrator" --shell="/bin/bash" --admin --version=1.0 --identifier="com.github.admin_user_setup" "Create Local Admin User Account.pkg"

Screen Shot 2017 12 23 at 9 35 43 PM

 

 

Screen Shot 2017 12 23 at 9 36 15 PM

 

When the package is installed, an account like this should now appear in the Users & Groups preferences in System Preferences.

 

Screen Shot 2017 12 23 at 9 36 41 PM

Screen Shot 2017 12 23 at 9 36 44 PM

 

Finally, let’s create a standard user local account with the following characteristics:

Account’s shortname: standarduser
Account’s displayed name: Standard User
UID: 603
Account shell: /bin/bash
Account should have admin rights: No
Account should auto-login: No

Since we also need to provide version and identifier information for the installer package, we’ll use the following characteristics:

Version number: 1.0
Package identifier: com.github.standard_user_user_setup

To create the installer package which installs the previously-defined local account, make sure you have a copy of pycreateuserpkg available, then use the command shown below:

/path/to/createuserpkg --name="standarduser" --uid=603 --fullname="Standard User" --shell="/bin/bash" --version=1.0 --identifier="com.github.standard_user_user_setup" "Create Standard User User Account.pkg"

 

Screen Shot 2017 12 23 at 9 34 57 PM

 

Screen Shot 2017 12 23 at 9 30 59 PM

 

When the package is installed, an account like this should now appear in the Users & Groups preferences in System Preferences.

 

Screen Shot 2017 12 23 at 9 33 16 PM

Screen Shot 2017 12 23 at 9 33 21 PM

 

How pycreateuserpkg works

pycreateuserpkg works by creating a plist file for the specified local user account, which allows the account information to work on 10.8.x and later. The user’s account information is written to a plist file and stored in the directory listed below:

/private/var/db/dslocal/nodes/Default/users

Screen Shot 2017 12 23 at 9 00 05 PM

 

An example account plist is shown below:

If the auto-login option is selected, an additional /etc/kcpassword file is also installed to facilitate the auto-login process.

Screen Shot 2017 12 23 at 9 00 11 PM

If the auto-login option is not selected, the /etc/kcpassword file will not be installed.

Screen Shot 2017 12 23 at 9 41 00 PM

Once the necessary file(s) are created by pycreateuserpkg, the utility then generates an installer package and post-installation script to install the account’s plist and the /etc/kcpassword file (if needed) into their proper places. An example postinstall script from a pycreateuserpkg-generated installer package is shown below:

Note: The postinstall script may have different functionality, depending on which options are selected. For example, this is the postinstall script generated for an installer package which installs a standard user account which is set to auto-login:

Once the pycreateuserpkg-generated package is installed, the account’s file(s) are put into the necessary places and the postinstall script handles any necessary preparation needed for the account to work properly.

Êtes-vous certain d'avoir le bon logo ?

Le logo est l’âme d’une startup. Son image, le reflet de son âme et de ses valeurs. Aussi je vais poser une question importante, vitale, essentielle :

Êtes-vous sûr d’avoir le bon logo ?

A-t-il la bonne forme ? A-t-elle l’air moderne, dans l’air du temps ? Faut-il choisir l’harmonie du cercle ou la brutale efficacité du carré ? Lequel s’affichera mieux sur l’écran d’accueil d’un iPhone ? Et d’un téléphone Android ?

Et la couleur alors ? La nuance de bleu choisie est-elle la plus efficace ? Peut-être que l’orange aurait plus d’impact ? Le rouge va-t-il être perçu comme percutant ou trop agressif ? Les couleurs offrent-elles un contraste suffisant pour les mal voyants ? La mode est-elle aux dégradés ou aux aplats ?

Plus important encore, la police de caractères. N’avez-vous pas utilisé une police de caractères trop utilisée ? Connaissez-vous son histoire ? Peut-elle être lue à distance ? Peut-être qu’une police personnalisée, construite sur mesure, serait plus adaptée ?

Vous voulez connaître le vrai secret pour faire un bon logo ?

Le secret du logo c’est que les gens normaux n’en ont rien à foutre.

Ces histoires de forme, de couleur, d’histoire de polices ? 99,99% des gens n’y connaissent rien et s’en contrefichent. Les Startups efficaces développent le meilleur produit possible, trouvent des clients, gèrent leur cash flow et ne perdent pas de temps sur cette connerie de logo.

Security Update 2017-001 being pushed to both macOS 10.13.0 and 10.13.1

To fix the vulnerability popularly referred to as #IAMROOT , Apple has begun pushing Security Update 2017-001 to Macs running the following OS versions:

  • macOS 10.13.0
  • macOS 10.13.1

This update is being deployed using the same automated installation mechanism that Apple previously used to deploy OS X NTP Security Update 1.0 back in 2014, where Security Update 2017-001 is being silently downloaded and installed on vulnerable Macs.

Screen Shot 2017 11 30 at 2 08 59 PM

For more details, please see below the jump.

To verify that Security Update 2017-001 has been installed, you should be able to check the Updates page of the Mac App Store (MAS).

If it hasn’t been automatically installed yet, it should appear as an available update.

Screen Shot 2017 11 30 at 3 39 18 PM

 

If it has been installed, it should show up in the list of installed updates.

Screen Shot 2017 11 30 at 3 43 47 PM

 

Something to be aware of is that the initial release of Security Update 2017-001 for 10.13.1 had a problem where file sharing did not work following the installation of the update. To address and fix the file sharing issue, Apple has released an updated Security Update 2017-001 for 10.13.1, which is being installed on both still-vulnerable Macs and also on Macs which had received the first release of Security Update 2017-001 for 10.13.1.

If your Mac received both versions of Security Update 2017-001 for 10.13.1, the list of installed updates in the MAS may look a little odd.

Screen Shot 2017 11 30 at 2 51 26 PM

However, nothing’s actually wrong. The double listing for Security Update 2017-001 means both releases of Security Update 2017-001 were installed.

If you need to verify via the command line that Security Update 2017-001 has been installed, use the procedure shown below:

On macOS 10.13.0, run the following command:

pkgutil --packages | grep com.apple.pkg.update.os.10.13Supplemental.17A501

If Security Update 2017-001 for 10.13.0 has been installed has been installed, the following output should be returned:

computername:~ username$ pkgutil --packages | grep com.apple.pkg.update.os.10.13Supplemental.17A501
com.apple.pkg.update.os.10.13Supplemental.17A501
computername:~ username$

 

On macOS 10.13.1, run the following command:

pkgutil --packages | grep com.apple.pkg.update.os.10.13.1Supplemental.17B100*

If only the initial release of Security Update 2017-001 for 10.13.1 has been installed, the following output should be returned:

computername:~ username$ pkgutil --packages | grep com.apple.pkg.update.os.10.13.1Supplemental.17B100*
com.apple.pkg.update.os.10.13.1Supplemental.17B1002
computername:~ username$

If only the latest release of Security Update 2017-001 for 10.13.1 has been installed, the following output should be returned:

computername:~ username$ pkgutil --packages | grep com.apple.pkg.update.os.10.13.1Supplemental.17B100*
com.apple.pkg.update.os.10.13.1Supplemental.17B1003
computername:~ username$

If both releases of Security Update 2017-001 for 10.13.1 have been installed, the following output should be returned:

computername:~ username$ pkgutil --packages | grep com.apple.pkg.update.os.10.13.1Supplemental.17B100*
com.apple.pkg.update.os.10.13.1Supplemental.17B1003
com.apple.pkg.update.os.10.13.1Supplemental.17B1002
computername:~ username$ 

Blocking logins to the root account on macOS High Sierra

A security vulnerability was discovered in macOS High Sierra today, where you could enable and log into the root account without providing a password.



Update 11-29-2017: Apple has released Security Update 2017-001 to fix this issue. Please install this update as soon as possible.




Update 11-30-2017: Apple is now automatically installing Security Update 2017-001 on vulnerable Macs.



To address this this issue until Apple releases an update to fix it, there’s two steps you can take which will block logins to the root account:

  1. Set a password for the root account on your Mac
  2. Change the root’s account’s login shell to /usr/bin/false

When you set the root account’s login shell to /usr/bin/false, the shell is changed to point to a command that does nothing except return a status code which reports an error. The login process will interpret that error status code as being a failed login, so it will stop the login process at that point and prompt for the password again.

Since the login process will always receive the error code from the false command, the login process will never succeed. For more details, see below the jump.

I’ve written a script which does the following:

  1. Sets the root account’s password to a random 32 character long password
  2. Sets the root account’s login shell to /usr/bin/false



Update 11-28-2017: After more testing of my script, I noticed one side effect of setting the root account’s password was that the root account was now enabled. I’ve added a section to the script to disable the root account again using Apple’s dsenableroot tool.

An admin user’s authentication is needed to disable the root account using the dsenableroot tool, so the script is using the just-set randomly generated password for the root account to provide the necessary authentication to disable the root account.

Never mind! It looks like disabling root just re-introduces the vulnerability all over again. Reverting my script changes.



It’s available on GitHub via the link below:

https://github.com/rtrouton/rtrouton_scripts/tree/master/rtrouton_scripts/block_root_account_login

This script is also available as a payload-free installer package, stored as a .zip file in the payload-free_package directory.

The script is also available here:

Le storytelling est... mort ?

La semaine dernière, quelqu’un a tweeté cette image1.

Storytelling Is Dead My Ass

Sincères condoléances, sans autre forme de procès et sans aucune autopsie le storytelling est déclaré mort et enterré. Par contre, c’est sûr, les affirmations gratuites sont bien vivantes, elles. Désolé pour ce monsieur, mais le storytelling est bien vivant, en pleine forme, et le sera tant qu’il y a des humains sur terre.

La preuve ? Chaque fois qu’un nouveau film est réalisé, le storytelling est vivant. Chaque fois qu’un livre est publié, le storytelling est vivant. Chaque fois qu’une histoire est racontée, le storytelling est vivant. Chaque fois qu’un bon orateur donne une présentation TED, le storytelling est vivant. Déclarer le storytelling mort pour créer un effet d’annonce est sans aucun doute provocant et attire l’attention —d’ailleurs cela a attiré la mienne— mais c’est tout simplement faux.

Le storytelling ne va pas disparaître car il est une partie intégrante de ce qui fait de nous des êtres humains. Depuis l’aube de l’humanité, depuis que nous avons acquis la capacité de communiquer et d’échanger par la parole, le storytelling a été présent. Pour simplement raconter des histoires, mais aussi pour transmettre notre savoir et nos valeurs morales. Même aux heures les plus sombres de l’humanité il y aura toujours des personnes pour raconter des histoires extraordinaires.

Le jour où le storytelling disparaîtra sera le jour où l’humanité disparaîtra.


  1. Le storytelling est mort, vive le storymaking [return]