macOS Admin privilage w/o Authentication Services

[mikawber]

I have an application that requires administrator privilege. I was able to use the Authorization Services to prompt the user for their password and then execute the command. However, I don't necessarily like the pop-up window and would much rather use a custom drop-down sheet to have them enter their password. Is it possible to get the correct authorization this way? If so, is it any less secure?

Thanks in advance!

 

[lee1210]

This is just my opinion, but I feel that circumventing the "standard" means of elevating privileges, and using your own method serves to break the security model. You shouldn't have access to their password in your code. They shouldn't decide if they should trust your app with their password or not, they should be presented with the request just like every other installer and app they use presents it. I know this isn't really helping you, but if the dialog that is presented is so out of place in your app, there might be something else going on you need to look into.

-Lee

 

[mikawber]

well then is it possible to place the popup window in a certain location relative to the application window?

 

[Consultant]

No. Not possible to make your malware.

 

[mikawber]

No. Not possible to make your malware.

If I was making malware do you really think I would be worried about where the freaking window is placed? I mean seriously don't reply if you can't help.

 

[gnasher729]

If I was making malware do you really think I would be worried about where the freaking window is placed? I mean seriously don't reply if you can't help.

If you try to do things requiring admin privileges without going through the standard methods to do this, you either plan to create malware, or you are one of those amateurs who think they can do security, and which are a major cause of the problems that Windows has with security.

Does that put you off? I hope it does.

 

[antibact1]

Apple has designed things to be consistent - a user exposed to a non-standard authentication will be confused by it and possibly suspect something is amiss.

 

[mikawber]

If you try to do things requiring admin privileges without going through the standard methods to do this, you either plan to create malware, or you are one of those amateurs who think they can do security, and which are a major cause of the problems that Windows has with security.

Does that put you off? I hope it does.

Have you ever used the popular utility OynX? The app has it's own drop down panel instead of the standard authorization window. This app is clearly not malware as I've used it (along with many other people) for quite some time. I doubt the developers are amateurs.

Apple has designed things to be consistent - a user exposed to a non-standard authentication will be confused by it and possibly suspect something is amiss.

I understand this completely and when lee1210 suggested I just use this anyways, I asked if it's possible to position the pop-up window to make the app look more neat. Is this possible to do?

 

[Krevnik]

well then is it possible to place the popup window in a certain location relative to the application window?

To answer your question: no.

You don't own the window. Your application doesn't own the window. You don't have access to the window or anything about it.

And this is how it should be. It isolates you and the token for privileges away from the user's password. And it isn't just about keeping you away from the password. What if your tool runs on the network? Any bug on your part could turn into exposing a user's password to attackers. SIMBL plugins technically could access the password as well if they knew what they were looking for (did they ever fix the huge risk these guys posed by letting them run in every process?).

Because the window lives outside your control, it is centered in the screen. Again, this is how it should be. It grabs the user's attention that something wants to elevate, and has details on who is trying to elevate. While the Vista method of overlaying the UAC dialog over the window of the app requesting privs is kinda nice... it isn't any more correct than Apple's way. They are both correct for different reasons. I wouldn't bend over backwards trying to re-engineer the authentication mechanism here, because in the end, you are spinning your wheels on something that is quite trivial. I just don't see that you would get enough user benefit here to make it worth the time to reimplement the window, and it could serve to confuse the user as others stated, which is the opposite of what you want to do.

And don't let other apps that have gone off the beaten path influence your judgement. Either an idea has merit or it doesn't on its own standing. And personally, I don't think taking over authentication dialog has merit. Sure, OnyX does it, but it doesn't mean that OnyX's developer is right.

I just tried the app out, and running it caused it to just start doing things without telling me what all will be involved, why it needs the password, or what giving it the password gets me. And this is after I had to give admin permissions to an installer that only copies a .app. Basically, the developer of OnyX did a whole chain of things that I would consider to be bad ideas on deployment, security, and what to do on first launch.

I still don't know what OnyX is supposed to help me do, because I wasn't allowed to see the interface until it got my password. Bad.

 

[mikawber]

To answer your question: no.

You don't own the window. Your application doesn't own the window. You don't have access to the window or anything about it.

And this is how it should be. It isolates you and the token for privileges away from the user's password. And it isn't just about keeping you away from the password. What if your tool runs on the network? Any bug on your part could turn into exposing a user's password to attackers. SIMBL plugins technically could access the password as well if they knew what they were looking for (did they ever fix the huge risk these guys posed by letting them run in every process?).

Because the window lives outside your control, it is centered in the screen. Again, this is how it should be. It grabs the user's attention that something wants to elevate, and has details on who is trying to elevate. While the Vista method of overlaying the UAC dialog over the window of the app requesting privs is kinda nice... it isn't any more correct than Apple's way. They are both correct for different reasons. I wouldn't bend over backwards trying to re-engineer the authentication mechanism here, because in the end, you are spinning your wheels on something that is quite trivial. I just don't see that you would get enough user benefit here to make it worth the time to reimplement the window, and it could serve to confuse the user as others stated, which is the opposite of what you want to do.

And don't let other apps that have gone off the beaten path influence your judgement. Either an idea has merit or it doesn't on its own standing. And personally, I don't think taking over authentication dialog has merit. Sure, OnyX does it, but it doesn't mean that OnyX's developer is right.

I just tried the app out, and running it caused it to just start doing things without telling me what all will be involved, why it needs the password, or what giving it the password gets me. And this is after I had to give admin permissions to an installer that only copies a .app. Basically, the developer of OnyX did a whole chain of things that I would consider to be bad ideas on deployment, security, and what to do on first launch.

I still don't know what OnyX is supposed to help me do, because I wasn't allowed to see the interface until it got my password. Bad.

Thank you for actually answering my questions. It makes sense, so I guess I'll have to deal with it. Thanks.

 

[iSee]

I feel bad for the overly negative responses you got so I dug around for a minute. This tech note implies that it is possible to do what you want and gives you a clue as to where to start looking.

Of course it also points out
(1) that it is unsupported; and
(2) why it isn't a good idea anyway.

(Off topic: IMHO, just becuase it's not a good idea to do what the OP is asking about doesn't mean it's wrong to ask the question. Geez.)

Edit: oops, here's the link to the technote: http://developer.apple.com/qa/qa2001/qa1199.html#//apple_ref/doc/uid/DTS10001725