Casper Remote creates hidden/invisible policies when pushing packages

[donmontalvo]

Nearly keeled over when I perused the JAMF change management logs and noticed a bunch of policies created using an unfamiliar naming convention (using pipes). My first thought was "who is doing this?!"

After some digging, we determined Casper Remote creates a hidden policy each time someone pushes a package.(*) This might sound trivial, but I'm going to leave this here in case anyone searches for invisible policies.

(*) Which is like serving a plate of beans and not including the steak and potatoes...I guess if you're in to monolithic packaging that would make sense.

[mm2270]

Don, nothing new. Its worked like this forever. At its heart, since the Casper Suite is, and always has been, a client -> server check in process, and not a server -> client push process, it needs to create these "on the fly" policies, get them scoped to the Mac or Macs that were selected by the admin in Casper remote, then SSH into each Mac and direct it to "check-in" to the JSS run the policy. That's just how it works.
If there's anything that should come from this, its perhaps a feature request to not have them show up in the 'regular' policy logs, but in their own separate tab so they don't end up cluttering the policy log view. We rarely ever use CR here, so they aren't a concern for us, but I can see how it could be confusing to see these policy logs in the regular policy log location, especially if you do a lot of Casper Remote work.

[donmontalvo]

@mm2270 Thanks for the insight. I didn't know Casper Remote was creating policies behind the scenes, it makes sense.

However, it appears the techs now need Create rights for Policies, that appears to be a security hole/bug.

I don't remember having to have that box checked in JSS <9. I'll open a ticket to see what Support says.

[jimlee]

This has always been the case even before version 9. Just give your techs Create but not Read privileges.

[donmontalvo]

Most likely the reason we never noticed at other large environments, is because we simply never allowed it. Allowing techs to select and push packages is probably the stupidest workflow ever used in any Mac environment.

Pushing packages...welcome to monolithic hell. :) May as well stab one's self in face.

[jhbush]

@donmontalvo or @mm2270 I've always wondered is there an easy way to clean this cruft with say Spruce or something else?

[thoule]

So if it's making hidden policies, why does it need SSH? Regular policies don't need SSH. Is it so that it can go in and tell the jamf binary to run that policy 'jamf policy -id 1234'....?

[brad]

I believe it changed somewhere in version 8. Suddenly techs could not use Casper Remote.

@thoule That's exactly what it does.

[Kaltsas]

I reported the requirement for Create Rights for Policies needed to use Casper Remote as a security flaw a couple years ago. JAMF came back that it is by design and I should put in a FR if I wanted that changed.

I am also 100% with you that we need a way to push something without having to add the target computer to the policy scope. Casper Remote as is tends to be too confusing for our front line desktop staff. Given the option they will walk out and log into Self Service to push a button than use casper remote. Being able to deploy policies, and restrict a casper remote user to only have access to those policies (not every package in the JSS) would be ideal.