Bootstrappr

A little while ago, I made a new Mac deployment tool available:

https://github.com/munki/bootstrappr

Bootstrappr is really nothing more than a Bash script that installs any packages it finds in an adjacent packages directory. There’s no GUI, no bells and whistles.

What is it for? Why would you use it?

You’d use it for installation-based deployment workflows on iMac Pro (and potentially any Mac).

Continue reading “Bootstrappr”

Advertisements
Bootstrappr

MacTech Conference 2017 Links

Here are some links from my presentation at MacTech Conference 2017, “Imaging is Dead: Now What?”

Der Flounder, “Imaging will be dead soonish”: https://derflounder.wordpress.com/2017/01/10/imaging-will-be-dead-soon-ish/

AutoDMG: https://github.com/MagerValp/AutoDMG

Imagr: https://github.com/grahamgilbert/imagr

DeployStudio: http://www.deploystudio.com

Apple, “Upgrade macOS on a Mac at your institution”: https://support.apple.com/en-us/HT208020

Apple, “APFS and Imaging”: https://help.apple.com/deployment/macos/#/apd545ec8b69

createbootvolfromautonbi.py: https://github.com/munki/macadmin-scripts/blob/master/createbootvolfromautonbi.py

Erik Gomez, Custom DEP series: http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-1-An-Introduction/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-2-Creating-a-custom-package-and-deploying-Munki/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-3-Best-Practices/
http://blog.eriknicolasgomez.com/2017/03/08/Custom-DEP-Part-4-The-Future/
http://blog.eriknicolasgomez.com/2017/04/05/Custom-DEP-Part-5-Dynamic-InstallApplication/
http://blog.eriknicolasgomez.com/2017/04/27/Custom-DEP-Part-6-Vendor-Announcement-and-Presentation/
http://blog.eriknicolasgomez.com/2017/07/27/Custom-DEP-Part-7-Getting-started-with-AirWatch-9.1.3/

Victor Vranchan, Munkiing around with DEP: https://groob.io/posts/dep-micromdm-munki/

MacTech Conference 2017 Links

Gatekeeper Configuration Data and XProtectPlistConfigData and Munki and Reposado, oh my!

If you haven’t read this already, please do:

http://macops.ca/os-x-admins-your-clients-are-not-getting-background-security-updates/

I’ll wait.

Done? OK. Concerned? No? Then you can skip the rest of this post.

If you are concerned, and would like to make sure your managed machines have these security updates, I have a solution for you — if it affects you (and you use Munki and Reposado; so what, about six people?)
Continue reading “Gatekeeper Configuration Data and XProtectPlistConfigData and Munki and Reposado, oh my!”

Gatekeeper Configuration Data and XProtectPlistConfigData and Munki and Reposado, oh my!

Preventing users from disabling FileVault 2

FileVaultI’ve seen a few online questions about how to prevent users from turning off FileVault 2.

The first line of defense, of course, is to not give admin rights to those users. As of Mavericks, however, there is an additional tool — you can use a configuration profile to prevent turning off FileVault (or at least disable the controls in the Security and Privacy preference pane — very clever users with admin rights might still able to turn it off using Disk Utility or the command-line diskutil tool).

Here is a configuration profile that disables the “Turn off FileVault” button in the FileVault tab of the Security and Privacy preference pane.

Since admin users can also remove configuration profiles, you should probably also lock this profile, requiring a password to remove it. That’s an exercise left for the reader, but here’s a starting point…

Add something like this to the PayloadContent array:

<dict>
    <key>PayloadDescription</key>
    <string>Configures Configuration Profile security</string>
    <key>PayloadDisplayName</key>
    <string>Profile Security</string>
    <key>PayloadIdentifier</key>
    <string>0dc319a0-c331-0131-eeb5-000c294ab81b.alacarte.ProfileSecurity</string>
    <key>PayloadType</key>
    <string>com.apple.profileRemovalPassword</string>
    <key>PayloadUUID</key>
    <string>65a90a90-c331-0131-eeb9-000c294ab81b</string>
    <key>PayloadVersion</key>
    <integer>1</integer>
    <key>RemovalPassword</key>
    <string>PrOf1leReM0v@lPa$$w0rdG0esHere</string>
</dict>
Preventing users from disabling FileVault 2

Still more on the XProtect Updater

Mike Boylan writes in a reply to my previous post:

…I have to respectfully disagree that disabling the auto-update mechanism for Xprotect should be done in organizations with managed machines. Do you disable the automatic update mechanism for your anti-virus software? Do you manually test every definition update and push each one out through Munki? I’d assume not. Xprotect (clearly) isn’t serving the same type of updates as Apple software update. It’s a malware prevention/blocking (and in some cases, removal) system. I won’t argue that Xprotect’s disabling of Java plugins will almost certainly have a larger impact across organizations than say something like a Sophos definition update, but nonetheless, the intent is still to protect systems. Xprotect and anti-virus software together are meant to serve complimentary roles. These Java plugins are being disabled because serious known exploits are being used in the wild. For a company that cannot function without version xyx of the Java plugin, does it make sense to make changes so that it can continue to operate effectively? Sure. But I doubt most organizations rely that heavily on a single plugin. Also, how many different types of updaters should we as admins be responsible for managing? There are already too many. For most admins, I don’t think it’d be a responsible decision to add Xprotect to the list.

Mike:

If Xprotect’s disabling of web plugins has not caused your organization any issues, or you are willing to react to any issues such disabling might occur in the future, it may well make sense to leave things as they are for your organization.

In my organization, the Java 6 web plugin is required to perform vital, daily business functions. When it doesn’t work, business functions are seriously impacted.

My argument might be subtle.

Apple is acting as systems administrator for machines by updating the XProtect plists. As long as you are content to let Apple make those changes, and won’t complain if Apple makes a change that breaks things for you, by all means, leave the XProtect updater mechanism alone.

If, on the other hand, _you_ are taking responsibility for managing your machines, making sure they are functional for your organization, and keeping them safe from malware, you’ll want to disable _Apple’s_ update of the XProtect malware definitions, and take over updating them yourself.

If you do not want to be surprised that one morning Java or Flash or some other plugin has been disabled on all the Macs you manage, you cannot let Apple update these definitions without your review. You must take responsibility for reviewing and implementing Apple’s changes, or a modification thereof.

Is this more work? Yes. Does it add risk to your organization? Probably. All security is a trade-off between functionality and protection. Malware protection that prevents my users from doing their work is not an acceptable trade-off. Apple has made one decision about the trade-offs, one that protects a great number of Mac users while negatively affecting a very small number of them. That is not the correct decision for my organization.

The only way I can ensure the correct decisions are made for my organization is to not leave the decision making process solely to Apple, but to instead review Apple’s changes and alter them if needed for the benefit of my organization.

Each organization needs to weigh this decision for themselves.

Still more on the XProtect Updater