How would you prevent a mass-reimage initiated by Casper?

[mikeh]

Our Casper admins are researching how to prevent admin users of the Casper environment (using either JSS or the Casper Utilities) from initiating an Emory University-type disaster, in which the management server could send out commands to all managed systems, erase the hard drive and deploy a new OS.

Has anybody encountered, or can think of, a scenario that where a IT tech - trained or otherwise - could initiate a mass reimaging of a Mac fleet? What I'm most concerned about are the ways in which a tech would "imaginatively" use the tools in ways that are unanticipated. What have community members done to prevent this kind of disaster from occurring in their environment? User restrictions in the Casper server itself? Continual training and education of techs? Hope-and-pray?

For background, we are a higher-ed institution running a single JSS instance configured with multiple sites, each of which generally corresponds to a college. Techs in one site generally don't have permission to access another site. While most sites only have a couple admins and a few dozen devices, we do have a couple sites that have hundreds of machines. The largest site has about 20 techs that can use Remote and Imaging to manage machines for the departments they manage within that college. Only a few techs have access to the Full Site settings to create scripts or packages. We have NetBoot servers scattered around campus for convenience for those areas with large numbers of Macs. The NetBoot images are configured to automatically run Casper Imaging.

Thanks everyone!

[stevevalle]

My first thought is to restrict Autorun Data from being saved to all machines in Casper. That way, even if a policy was created for a machine to reboot to your netboot server, there's no configuration to be deployed and Casper Imaging will sit at the login screen.

[bentoms]

Pretty much what @stevevalle said.

Kill the auto run, setup configurations as you need & make folks authenticate in Imaging & then select a config.

[mikeh]

Let me start with an example that I can think of: when using AutoRun configuration data, setting both the "Image Automatically" and "Skip delay when imaging automatically" options is a disaster waiting to happen. My general thought, though, is that it would be difficult to do this accidentally to more than one machine, especially if you discourage their user and the techs are only interesting in using Imaging to deploy a pre-configured configuration. Sure, after-the-fact you could set AutoRun data and the appropriate options for a group of machines within the JSS, and then somehow initiate that group of machines to NetBoot, which (in our environment) would automatically start Imaging and thus start the reimaging. To me, though, the number of steps involved strongly implies malicious intent. Preventing Imaging from running automatically would stop an accidental deployment, but only slow down a malicious actor.

[stevewood]

@mikeh In addition to AutoRun data, you'd probably also want to limit your PreStage Imaging configs too, or clean them out once a device has been imaged, assuming you use PreStage Imaging. Granted, in order for PreStage to become an issue a tech would need to delete the computer from the JSS and boot the computer off of a NetBoot or other device that had Casper Imaging set to auto launch. Like you said, more a malicious actor type thing than an accidental re-image.

The only way I can see there being an accidental re-image with either AutoRun Data or PreStage data, would be the end user accidentally holding the N key down during boot. Or even holding Option key and being curious about the NetBoot images they see. Again, PreStage would need the machine to be removed from the JSS for it to run, but AutoRun would run automatically.

[mikeh]

@stevevalle @bentoms Thanks for the responses. My post above was intended to be the first post; I had posted it right after creating the discussion, but it was held for moderation.

Here's hoping (?) somebody knows of a "creative" way to wipe out a bunch of machines through Casper.

[mikeh]

Thanks @stevewood! I do love me some PreStage Imaging for my computer labs (until we settle on a DEP workflow, that is), so I don't want to completely restrict it. The suggestion to clear them out when the machines are completed is excellent advice.

Appreciate your comments!

[kitzy]

My approach to this would be the same as my approach to anything else I do that affects a large number of machines.

Build a test environment.

Test the intended workflow / changes.

Test it again.

Document everything.

Make the changes in production.

[bentoms]

@mikeh some other thoughts:

There isnt a mass action for the mdm command to wipe computers like there is for iOS but people could still send out a wipe computer command from each record. very powerful, very destructive. It is a privilege that can be taken away at the JSS user level.

There is also the risk of "rm -rf /" being sent via Execute Command in a policy or via script, which there is no way to prevent that. Only audit trails after the fact. You can remove ability to update or create scripts in the user permissions but that may hinder other needed things.

Or in scripts doing things like "rm -rf /Users/$username/Folder/Folder/" and due to how they are getting $username it was actually deleting the user directory.

Also in 10.11 an "rm -rf /" will just delete the user data and anything added to the computer yet should leave the OS intact due to SIP, similar to an iOS wipe. But its the user data that is at risk here.

Sometimes a bad or misused packages bricking computers. Whether thats a dmg with FEU and other mis configured data or a pkg with a script that has destructive properties it doesnt matter. Like somebody accidentally pushing out a full OS dmg over top of existing computers instead of caching the newest OS installer app from the app store for the in place upgrade workflow.

Basically, the JSS does things elevated privileges, if you tell the JSS to do something on computers, it will do it. Hence the NEED for a test environment and all things being vetted and moved through that process. Like what @kitzy is recommending.

[mikeh]

@bentoms Thanks for mentioning the MDM commands. I had forgotten about them because I rarely use them.

Scripting and malformed packages are always going to be a problem, but we generally restrict most techs from creating either within the JSS. I didn't think there was anything we could do about restricting the ability to execute commands via Remote and policies, like you stated. Good to have an authority say it.

@kitzy @bentoms A formal test environment would be nice, indeed.

I'm very glad I posted. Thanks again!