Categories
Mac admin'ing

Allowing Outset-run scripts to have access to user folders

Because of TCC/PPPC, which Apple introduced in macOS 10.14, scripts and applications have to ask for permissions to do certain things, especially things like reading user home directory files.

If you have an Outset login script that tries to access something in the home directory, you may find in the ~/Library/Logs/outset.log that you get a Failure processing [name of script, command that failed] Operation not permitted error.

I tried creating a PPPC profile for the script itself. That didn’t work. I tried creating a PPPC profile for /usr/local/outset/outset. That didn’t work. I tried creating a PPPC profile for /bin/zsh. That didn’t work. I tried creating a PPPC profile that allowed all three to have access to all files. That didn’t work.

So, finally, I ran a tccutil reset All to reset the database, and then I logged in again, and it asked for Python to have access to the home folder the script was trying to read.

So I created a PPPC profile to allow Python (the one Outset is using) to have access to the home folder the script was trying to read, and the script ran just fine.

I’m not an expert on this, and any follow-up questions you have would probably be best directed to the #outset channel on the MacAdmins Slack (I’m over there too) instead of in the comments of this post (blog comments aren’t a great venue for tech support), but I thought sharing one case that worked might be helpful for others running into the same issue.

Categories
Mac admin'ing

If Jamf recon is launching a du process that causes a CPU spike

If Jamf inventory (jamf recon) causes an extended CPU spike specifically related to the du command, you can fix that by going, in the Jamf settings, to Computer Management > Computer Management – Management Framework > Inventory Collection, and then uncheck the Include home directory sizes checkbox.

That is a system-wide setting, but especially if most or all of your fleet is one-to-one Macs (not shared Macs), it’s a good idea to do. Your jamf recon inventory runs will still report back free disk space, just not broken down by individual home directories.

Special shoutout to tlark and neilmartin83 on the MacAdmins Slack for giving me more context around this.

Categories
Mac admin'ing

Terminal command to tell if a macOS directory is SIP-protected

Starting with El Capitan (OS X 10.11), Apple started using System Integrity Protection (SIP) in macOS, so that certain directories would be not writable, even by root. Here’s a quick reference for a couple of commands you can use to see if a directory or file is SIP-protected, as that may change from macOS version to macOS version.

Method 1

ls -lO (that’s a lowercase L, followed by a capital o, not the number 0), and look for restricted.

Example: ls -lO /Library/Updates/
total 2224
-rw-r--r--@ 1 root wheel restricted 181 Jul 29 10:22 PPDVersions.plist
-rw-r--r--@ 1 root wheel restricted 1130219 Jul 29 10:22 ProductMetadata.plist
-rw-r--r-- 1 root wheel restricted 260 Jul 29 10:17 index.plist

Method 2

xattr -l (that’s a lowercase L) and then the name of the directory. Look for com.apple.rootless

Example: xattr -l /Library/Updates/
com.apple.rootless: SoftwareUpdate

Special thanks to @revolize and @Magneto on the MacAdmins Slack!

Categories
Mac admin'ing

Scripting SSH off/on without needing a PPPC/TCC profile

You used to be able to use /usr/sbin/systemsetup -f -setremotelogin off or /usr/sbin/systemsetup -f -setremotelogin on to script disabling or enabling SSH on macOS.

Now that macOS has Privacy Preferences Policy Control, which needs a profile delivered by a user-approved MDM, you may get this error: setremotelogin: Turning Remote Login on or off requires Full Disk Access privileges., which can be especially annoying if the script’s parent process isn’t code-signed (and thus can’t be used in a PPPC profile), as /usr/sbin/period isn’t, for example. (Read more at Use the systemsetup command-line utility on macOS Catalina 10.15.)

For now, a workaround for this is to simply load or unload the launch daemon that enables/disables SSH: /bin/launchctl load -w /System/Library/LaunchDaemons/ssh.plist or /bin/launchctl unload -w /System/Library/LaunchDaemons/ssh.plist

P.S. Since these are things you’re scripting via something like Munki or Jamf, I’m assuming you’re testing the commands as root.

Categories
Mac admin'ing

Running daily, weekly, and monthly scripts in macOS using periodic

Background

I was looking for time-based project similar to Outset (which runs boot and login scripts stored in various directories), and apparently there’s one already baked into macOS that will run daily, weekly, and monthly scripts.

Shoutout to @elios on the MacAdmins Slack for letting me know about periodic

Launch Daemons

If you run sudo launchctl list | grep periodic-, you’ll see that these launch daemons are running:

com.apple.periodic-monthly
com.apple.periodic-weekly
com.apple.periodic-daily

And, though I don’t love SIP in general, it’s great for this, because you can’t actually disable the launch daemons:

sudo launchctl unload /System/Library/LaunchDaemons/com.apple.periodic-daily.plist
/System/Library/LaunchDaemons/com.apple.periodic-daily.plist: Operation not permitted while System Integrity Protection is engaged

So that means as long as you can enforce your daily, weekly, and monthly scripts being in the right place, with the right permissions, and with the right hash, they’ll be run regularly-ish.

Locations of Scripts

You can find scripts in /etc/periodic/daily, /etc/periodic/weekly, and /etc/periodic/monthly. You can also put your own scripts in there (root-owned, 755 permissions), and they’ll run alongside the ones that come with macOS.

According to /etc/defaults/periodic.conf, though, there’s another recommended place to put scripts:

# periodic script dirs
local_periodic="/usr/local/etc/periodic"

So that would be /usr/local/etc/periodic/daily, /usr/local/etc/periodic/weekly, and /usr/local/etc/periodic/monthly. Having your scripts separated from the built-in scripts may be a good idea, even though they’ll run fine alongside the built-in scripts.

Logging

If your script has any echo commands, the output will go to the appropriate log file (by default, those logs would be /var/log/daily.out, /var/log/weekly.out, and /var/log/monthly.out), but there won’t necessarily (again, with the default settings) be any other indicators in the daily, weekly, and monthly logs that your scripts ran.

The format of the log seems to be a date/time, all the echo statements from the scripts run, and then a closer like -- End of daily/weekly/monthly output --.

Invoking manually

If you don’t want to wait until the next day, week, or month, you can do some manual testing by running a command like this, for example: sudo periodic daily

No TCC/PPPC support

Allowing full disk access to a script relies on giving that access to the actual parent process. As far as I can tell, the parent process is the /usr/sbin/periodic binary, but that binary (although shipped with macOS) isn’t code-signed.

Categories
Mac admin'ing

The limits of password-protecting a .mobileconfig profile

Three years ago, Rich Trouton wrote Adding password protection to manually installed management profiles, which gives step-by-step instructions for how to make a manually-installed profile prompt for a custom password (in addition to the local admin password) when being removed.

I’ve tested this on Catalina, and it still works!

That said, it worked only from the GUI (via System Preferences). If you remove the sample profile (sudo profiles remove -identifier 9f9a0b1f-7b17-4656-92aa-b7046ad88d00), it will just remove immediately with no custom password provided.

Your best bet for making a profile non-removable is to install it via MDM.

Categories
Mac admin'ing

Double-checking details of deployed PPPC/TCC profile from MDM

If you’ve deployed a PPPC/TCC profile from your user-approved MDM to a Mac, and you see the profile in System Preferences > Profiles, you can also verify all the details of the deployed profile on the Mac itself by going to /Library/Application Support/com.apple.TCC/MDMOverrides.plist (which is an SIP-protected directory, by the way).

Categories
Uncategorized

Setting the date/time in macOS (10.14+) recovery mode

Back in ye olde days, you used to be able to run ntpdate -u time.apple.com to update the date/time automatically in recovery mode, but Apple removed ntpdate in Mojave.

In regular bootup, you can run sntp -sS time-a.nist.gov and may get an error like kod_init_kod_db(): Cannot open KoD db file /var/db/ntp-kod: No such file or directory, but the date and time actually will update properly. If you try that command in recovery mode, though, the date and time will not update.

Similarly, in regular bootup, you can run systemsetup -setusingnetworktime off && systemsetup -setusingnetworktime on to resync the date/time, and that totally works. In recovery mode, there is no systemsetup command.

So what do we have left in recovery mode?

You can use the date command to set the command manually. Just keep in mind that booted into regular mode, you’re usually going to see the date/time in your local time zone, whereas you’ll see the date/time in UTC when booted into recovery mode.

To update the time to, for example, 2:25pm PDT (so 9:25pm UTC) for June 3, 2020, you’d run a command like this in recovery mode:

date 0603212520

That’s 06 (June) 03 (the date) 21:25 (9:25pm on a 24-hour clock) 20 (the year, 2020).

P.S. @ClassicII on the MacAdmins Slack did testing and found sntp binary works fine in recovery mode. I did my own testing and found it did not. So, your mileage may vary? Maybe give it a shot, but… yeah, you may have to fall back to manually setting the date/time if it doesn’t work.

Categories
Mac admin'ing

Things to keep in mind if using a profile to delay macOS updates

Now that Apple has removed the --ignore flag from softwareupdate, it’s recommending you use the forceDelayedSoftwareUpdates and enforcedSoftwareUpdateDelay flags (more details in Device Management Profile: Restrictions), which are supposed to, in theory, delay an updates user visibility a certain number of days after the update’s release.

The number of days delayed may not be precise

The number of days delayed is imperfect at best. I tested a 7-day delay and even 6 days after the release of the update, it was suddenly available. And here’s an example of someone last year who didn’t see an update released 10 days before, even with only a 7-day delay.

System Preferences and softwareupdate may not be in sync

In my own testing, if you delay an update but a Mac is two or more updates behind, softwareupdate -d -a or softwareupdate -l will still show an update available to download, but System Preferences > Software Update will show Your Mac is running the latest software update allowed by your administrator.

That can be a problem if you rely on a program like Nudge, which uses softwareupdate to determine whether an update is available but points users to System Preferences to do the actual update.

At this time, unless Apple makes significant changes, I wouldn’t recommend using the delay update profile settings if you have any utilities that use softwareupdate to check whether updates are available or not.

Categories
Mac admin'ing

How to deploy a .pkg via Munki if a config file has to be in the same directory

Vendors package software in funny ways sometimes. Every now and then, you might come across a vendor .pkg that comes with some kind of .xml or .cfg or .txt that has to be in the same directory as the .pkg. It’s likely because there’s some postinstall script in the .pkg itself that references that text file via relative path.

There are basically two approaches you can take here with Munki.

Approach #1 would be to create another .pkg that delivers that .pkg as a payload to a directory of your choosing (e.g., /tmp) and also delivers the config file to that same directory. Then, in your custom .pkg, you have your own postinstall script that runs something like installer -pkg /tmp/nameofpackages.pkg -target /

Approach #2 is what I’d recommend, if you’re using Munki, which would be manually creating a disk image that has both the .pkg and config file in the same directory, and then importing that disk image into Munki. Munki mounts .dmgs to an arbitrary random mount point, but since the .pkg and config file will be in the same directory within the mounted .dmg, it won’t matter, and when Munki sees the .pkg inside the .dmg, Munki will just install the .pkg, and everything will be cool.