AV install on OS X 10.13+ endpoints (non-admin users)

Content Authoring
1

I need to install a new antivirus app to our Mac population. Many have admin rights, but not everyone. I’m in a highly distributed organization where I don’t have much control over, or detailed knowledge of, the endpoints.

I’ve got a couple of challenges that I am looking for some creative solutions to resolve.

I can install the AV app as easily any other, that’s pretty simple. What I can’t do is approve KEXT or full disk access. I have to rely on end users to approve these after a reboot. It’s not elegant, but it’ll work. But, what if the user has no admin rights? They can’t approve the extension or disk access. If this happens, the user will have no functioning antivirus application and they’ll continue to get prompts to approve things they don’t have permissions to install.

So what I want to do is run this only if the end user is an admin. The ‘Users’ tab in the ‘Take Action’ dialog in the BigFix console provides this ability on Windows endpoints, but it doesn’t work for Macs.

My thought here is to run the installer as the currently logged in user, if they don’t have admin rights the installer will fail right away and I can have local support deal with this installation another way.

I can’t get override wait; runas=currentuser, or runas={name of current user as string}, to work. The fixlet will complete, but the .pkg is never run.

I’m thinking that the best I can do is to copy the installer.pkg to the desktop of the currently logged in user and prompt them to install it.

Any suggestions for running as the currently logged in user or with automating the KEXT approvals would be very much appreciated.

b

2

Is this a result of Apple “removing” certain rights from root (that BigFix runs under)?

3

Yes it is, at least in large part.

runas = current user, however, appears to have been unreliable for some time. I don’t need it often and my results may be from a lack of experience with that particular method?

I found another way around the particular issue that I was trying to address by running as current user.

Since I need an end user to take actions after the install, I need to know if the currently logged in user is an admin. So I test for it with:
delete /tmp/ISADMIN
wait /bin/sh -c "id -Gn {name of current user as string} > /tmp/ISADMIN"
continue if {exists file "/tmp/ISADMIN" whose (line of it contains " admin ")}
delete /tmp/ISADMIN
...

This feels kind of “hack-y”, but it works for the action script. It’s not what I’d want to base a property on.

To make this into a property I’d have to deploy an action to run the id command way too often and have an analysis read that file at least as often as it gets written. It’s possible to do and would probably even reliable. Thinking through how it would have to work makes me feel like it’s too heavy of an action run often enough for it to be useful. And how much longer will Apple allow that command be available to root?

4

Can I create a custom exit code when the continue if evaluates to false? The action Status is Waiting and has an Exit Code of 0. I’d like to make it obvious in some way that this was not successful because the user wasn’t an admin.