As part of a discussion of security issues with some colleagues this morning, the question of how to disable Bonjour advertisement came up on OS X El Capitan and later came up. Bonjour advertisement is how your Mac sends out an “I’m here and this is a list of the services I have available” message via Bonjour. In certain environments, this is undesired behavior and the advertisement service needs to be disabled.
The reason why the question came up is that, on OS X Yosemite and earlier, the process of disabling Bonjour advertisement looked like this:
1. Run the following command with root privileges to unload the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:
launchctl unload /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
2. Run the following command with root privileges to edit the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:
defaults write /System/Library/LaunchDaemons/com.apple.mDNSResponder ProgramArguments -array-add &quot;-NoMulticastAdvertisements&quot;
3. Run the following command with root privileges to load the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file:
launchctl load /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist
As of OS X 10.11.x though, System Integrity Protection blocks the editing of the /System/Library/LaunchDaemons/com.apple.mDNSResponder.plist LaunchDaemon file because of the file’s location inside of the SIP-protected /System directory.
To accommodate this change, Apple made a change to mDNSResponder on OS X El Capitan and later to allow it to pick up settings from the following file:
The ability to disable Bonjour advertisement is among the settings which can be applied to the new /Library/Preferences/com.apple.mDNSResponder.plist file. To disable Bonjour advertisement in OS X El Capitan and later, use the following procedure:
1. Run the following command with root privileges:
defaults write /Library/Preferences/com.apple.mDNSResponder.plist NoMulticastAdvertisements -bool YES
2. Restart the Mac
3. Once the Mac has restarted, Bonjour advertisement should be disabled.
For those who want to disable Bonjour advertisement using a management profile, I’ve created a .mobileconfig file and posted it here on Github:
Update – 8-22-2016: My colleague Steve Yuroff tested the profile independently and let me know that this may not be manageable via a profile after all. I re-tested and was able to reproduce his results. We have both verified that running the defaults command listed above does produce the expected behavior.
I’ve filed a bug report about this. For those interested in duping this bug, the bug report ID is 27952362. I’ve also cross-posted it to OpenRadar:
As part of the process of upgrading my Casper server, I generally create a new installer for the Casper agent in the form of a QuickAdd installer package. This process usually looks like this:
1. Update the Casper Suite applications on the Mac where I’m generating the new QuickAdd installer package.
2. Open Casper Recon.
3. Sign into Casper Recon.
4. Select QuickAdd Package from the Recon sidebar.
5. Set up the desired options for the QuickAdd installer package.
6. Click the Create button.
7. Choose a name for the new QuickAdd installer package.
8. Wait for Recon to create the QuickAdd installer package.
9. Take the newly-created QuickAdd package and use it to replace the existing QuickAdd packages used by CasperCheck and my deployment workflows.
The reason I use this process is that Casper’s Recon application is able to generate a QuickAdd installer package with an unlimited enrollment invitation. With an unlimited enrollment invitation, I can use the same QuickAdd installer package multiple times to enroll multiple machines. This is in contrast the user-based enrollment process via the JSS, which by default generates a QuickAdd installer package with a one-time-use enrollment invitation.
I have this Recon-based process documented, but it’s always been something I’ve wanted to automate at least somewhat. Recently, as part of a discussion with my colleague Tom Larkin, I learned that a Casper JSS server which is configured to send out emails is capable of generating enrollment invitation emails, which include a link to download a JSS-generated QuickAdd. That invitation can be set to link to a QuickAdd with an unlimited enrollment invitation and an expiration date many years in the future, which effectively gives me the ability to generate the QuickAdd installer packages I want without the need to use Casper’s Recon application. For more details, see below the jump.
As a follow up to yesterday’s post about setting up smart groups which automatically include a specified operating system and later, my colleague Erik Gomez sent me a heads-up about a new feature in Casper 9.93:
As part of Casper 9.93, JAMF has included new smart group operators as part of supporting its new patch reporting feature. The Operating System Version is one criteria which was updated and it now has the following operators available:
- Is Not
- Not Like
- Greater Than
- Less Than
- Greater Than or Equal
- Less Than or Equal
The new Greater Than and Less Than operators can completely replace the technique I’ve been using, as they make it straightforward to specify an operating system version number and then set the appropriate operator to automatically include all Macs whose OS version numbers are greater or less than the specified version number. For more details, see below the jump.
As part of setting up Casper policies, you need to set which Macs will be receiving these policies by setting the scope. The scope defines which Macs or users will be receiving these policies.
When preparing to set the scope for a policy, I will often build and use smart groups. These are a special kind of group, where the members are defined based on one or more attributes (like the Mac’s operating system version, IP address, Mac model, etc.) and therefore the group’s membership is dynamically growing and shrinking based on the numbers of Macs with the specified attributes.
Once the smart group has been set up with the desired attributes, I then set the smart group and its membership to be specified as the scope’s Target Computers.
For many software deployment policies, the software in question often has system requirements that cover a range of operating systems instead of just one version of Apple’s OS. For example, Google Chrome 52.0.2743.116 has the following system requirements:
OS X Mavericks 10.9 or later
Update 8-5-2016: Casper 9.93 and later includes new smart group functionality which can entirely replace the technique described in this post. For more details, please see the post linked below:
To deploy Chrome via Casper, the smart group should be set up with attributes that include Macs running 10.9.x. and later. To accomplish this, I had previously set up a smart group that looked like this:
Note: The trailing period after the last number is used by Casper to include all relevant matches. So “10.10.” will also pull in Macs running the following versions of OS X:
However, I was finding that I later needed to go back on an annual basis to those smart groups and add new entries. For macOS Sierra, the smart group would need to be edited to look like this:
An discussion with my colleague Jeremy Reichman provided me with a solution to this issue. I had been setting up my smart groups to include those machines which has the OSs I wanted by setting the smart group attributes to say “I want these OS versions.”
A better answer is to say “I don’t want these OS versions,” and then specify the OS versions that are NOT wanted in your smart group. The result is that your smart group is then populated with whatever is left after excluding the unwanted versions. For example, to get all Macs running 10.9.x or later, you can set up a smart group that looks like this:
Note: It’s unlikely to have 10.1.x through 10.4.x in a modern Mac environment but they’ve been included for completeness’ sake.
The resulting smart group membership should include all the machines that aren’t running the specified OS versions, which may include Macs running 10.9.0 through 10.999.999.
This makes the job of scoping a Chrome software deployment policy easier because the smart group membership will now automatically match the specifications of Google Chrome’s system requirements of OS X 10.9 or later.
One of my customers reported an unusual problem today with their keyboard, mouse and trackpad. When they tried to to use Apple’s Mail or Messages applications on OS X El Capitan, both Mail and Messages were unresponsive to either keyboard, trackpad or mouse input.
However, when they selected another non-Apple application like Firefox or Google Chrome, their keyboard, trackpad and mouse behaved normally. Other Apple-installed applications like Safari were also responsive to keyboard, trackpad and mouse input.
When I checked the logs, the main clue I could find was that when I clicked on Mail or Messages, I would see an entry like this appear in /var/log/system.log:
09:02:06.100 sandboxd: () Mail (458) deny hid-control
hid in this instance refers to something which Apple classifies as a Human Interface Device, which include the following devices:
- Keyboards and pointing devices such as mice, trackballs, and joysticks
- Front-panel controls such as knobs, switches, sliders, and buttons (for example, controls on non-Apple displays)
- Controls that might be found on games or simulation devices such as data gloves, throttles, and steering wheels
So for some reason the sandboxd process was denying access to Messages and Mail for the mouse, keyboard and trackpad. Why? For more details, please see below the jump.
To go along with a previous post about automating Oracle Java 8 updates, I’ve now posted a script to download and install the latest Java 8 Java Development Kit (JDK) from Oracle. Oracle has been releasing two separate versions of Java 8 simultaneously, so this script is 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:
For more information, see below the jump.
An issue that can pop up for new Mac admins is whether or not to enable the root account on the Macs in your environment. By default, the root account on OS X and macOS is a disabled account with the following settings:
Display name: System Administrator
Account name: root
Home directory: /var/root
User shell: /bin/sh
The root account is the superuser for a Unix-style operating system like OS X and macOS and Unix is designed to let the root account have total access to everything. When asking what root can do on a system, it may be better to ask what root cannot do because that list is very, very short. Because the root account has enormous power on a Unix system, you may believe that enabling the root account and using it for your system administration tasks is a no-brainer.
In fact, the opposite is the case: It’s better to leave the root account disabled and not use it for system administration.
Why should you avoid logging into the root account and running tasks from there?
- Mistakes happen – When logged in as the root account, you have total access to the system and anything you run while logged in as root will just happen. That also means you can do a lot of damage if you make a mistake.
- Malware and software bugs – Being logged in as the root account means that all the applications you’re using are running with the root account’s privileges. That means every vulnerability and bug in those applications can potentially cause havoc on your system because anything that’s executing an undesired behavior or exploiting a vulnerability in a particular application is doing so using the root account’s rights to go anywhere and do anything on your system.
- Auditing: If multiple people are logging into the root account and using it for system administration, that means that the account in question isn’t necessarily tied to a single person and actions taken while logged into the root account aren’t necessarily logged. That makes it harder to figure out after the fact who did what if there’s a problem.
- It’s not necessary: The sudo command line tool is available and installed by default on both OS X and macOS. sudo is a Unix program which allows a user with the correct sudo rights to execute a command using the security privileges of another user account, with the root account’s security privileges being used by default.
Using sudo is safer than using the root account for the following reasons:
- Nobody needs to know the root account’s password – sudo prompts for the current user’s password and will check to see if the user which is trying to use sudo has the necessary rights for sudo to run the requested commands with root privileges.
- The granting of root privileges is temporary – By default, sudo will time out after fifteen minutes and will require re-authentication before running commands again.
- Only those commands run via sudo are using root privileges – Only the commands run using sudo will be run with root privileges. Meanwhile, commands run without sudo are being run without root privileges, which reduces the potential for damage from making a mistake.
- sudo use is logged – When a command is executed using sudo, the command and the account which used sudo to run it are logged. Likewise, unsuccessful attempts to run commands with sudo are also logged. This provides an easy way to look up which commands were run and who ran them.
For more information on using sudo, see below the jump.