Questions about privilege escalation on macOS

1. Is there a way to get AuthorizationCreate to display the authentication dialog with Touch ID? I see LocalAuthentation can display a TouchID dialog.

No.

This isn’t a technical issue but a policy choice [1]. The code that displays the authentication alert only shows the Touch ID option for Apple clients.

2. Is there (apart from AppleScript) a non-deprecated way to simply request authorization, launch a helper with privileges and arguments, then easily obtain the results from it?

No.

Having said that, I don’t consider the AppleScript approach (do shell script … with administrator privileges) to be a valid alternative to the long-deprecated AuthorizationExecuteWithPrivileges (AEWP). I view the AppleScript facility as equivalent to sudo: It’s intended to be used by system administrators, and not as API. If we could deprecate the AppleScript approach in the context of an app running an AppleScript, we would.

3. I get the impression that with SMJobBless (a non-deprecated API, but a ton of work), the helper will then permanently have escalated privileges, surely this is less secure?

That depends on how you look at it. The problem with AEWP is that there’s no secure link between the code asking to elevate privileges and the code that’s run with elevated privileges. SMJobBless fixes that.

However, its design, where the privileged helper tool retains its privileges, certainly engenders some security risks. You must write that code securely.

4. Also with SMJobBless, it appears that I need to use an installer package to install the helper in the correct place, is this correct?

No. The point of SMJobBless is that you can avoid the installer package.

If you already have an installer package in play, there’s no need for SMJobBless. The package can install a launchd daemon directly.

5. Is there a replacement for SMJobSubmit in the works?

I can’t talk about The Future™. However, given that it was deprecated almost 8 years ago and there’s been no movement since then, I wouldn’t hold your breath.

As always, if you have specific requirements in this space, I encourage you to file an enhancement request describing them.

6. What am I missing, or misunderstanding?

It’s hard to say without more context. Most notably, why are you escalating privileges in the first place?

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"

[1] And don’t ask me to explain policy or I’ll start to whimper (-:

Hola Quinn, Thanks for the terrific reply.

It’s hard to say without more context. Most notably, why are you escalating privileges in the first place?

One of the many things App Wrapper does as part of it's process is to ensure correct permissions on the files within the application bundle, but it fails when the customer doesn't have permission to alter to the permissions of a file.

Another task it does it does is to strip ACLs and Xattrs, sometimes customers have screwed up ACLs that prevent the ACLs from being removed, and/or prevent xattrs from being removed.

In this case, these actions can be done via API or via system commandline tools.

No. The point of SMJobBless is that you can avoid the installer package. If you already have an installer package in play, there’s no need for SMJobBless. The package can install a launchd daemon directly.

That's good to know, as I don't use an installer package for my apps, and it means I misunderstood some aspects.

That depends on how you look at it. The problem with AEWP is that there’s no secure link between the code asking to elevate privileges and the code that’s run with elevated privileges. SMJobBless fixes that.

I kinda guessed that when I saw how complicated it was to interact with the helper, v.s. just using AEWP. I don't know if it's really that necessary for my current needs. However it looks like it might be the only recommended choice.

However, its design, where the privileged helper tool retains its privileges, certainly engenders some security risks. You must write that code securely.

This scares the crap outa me, as it makes me afraid that I do something wrong, I put my customers at risk, I guess you could say that with all the mechanisms we've discussed, but this feels like a big red flag.

Thanks Quinn, you've given me some more information to ponder. I still currently don't know which direction to take, but hopefully after some percolation, I'll make be able to make a better decision.

Sam Rowlands

p.s. I guess you've seen the appreciation thread happening on Twitter :)

it fails when the customer doesn't have permission to alter to the permissions of a file

Are you talking permissions? Or ownership? It’s hard to think of cases where the user owns a file but doesn’t have the privileges to modify its privileges. And if the user doesn’t own the file, I think that making a copy that the user does own would be a better choice.

Keep in mind that, on APFS, copies are cheap in terms of both time and (disk) space.

I guess you've seen the appreciation thread happening on Twitter :)

You guessed right (-:

Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"