The helper tool only executes the tasks that would need elevated privileges.
For example only writing ti the /Library directory would be done by the helper. All other tasks will be done by the main program.
I think the idea is to restrict the helper to those elevated privileged tasks only, so the helper stays as compact and less of a risk as possible.
(doesn't mean I agree with this approach)

AppleScript: you'd be able to use something like RunCommand to run a script that does what needs to be done.
I'm not sure how good of an approach that will be fore your purpose.
Let's say you have a config file, then maybe the Apple Script could copy it to /Library/Application Support.

I don't have an example laying around though 😞 

Let me know what you think of CrossVCL - this could be something that could be pull me back in developing with Delphi again.
I've done development with Delphi on and off since Delphi 1.0 - and it offers iOS and Android, so that would be a bonus.

Posted by: @johngaver

Your posts are truly full of rich resources - as is the forum at large - thank you so much

Thank you and you're most welcome! Always nice to a conversation with people that share an interest 😉 

Right, I think I've seen some other projects by KSDev previously, and was happy with them. I'd be surprised if this latest effort of theirs wouldn't be up to par as well.

So to run AppleScript, I don't need to use any funky API calls - just doing it via an external process call is enough? Sounds easy enough.

However the mystery remains how VMware InstallBuilder are doing it. Just looking at their screenshot, given the console window elevation icon and text, I am really tempted to think they're using the deprecated method. But you mentioned having tried that and it just not working. Is there any way we can research this in detail? I've even launched a project on Upwork for this:

https://www.upwork.com/jobs/~01f7b9b74fb05f1ff9

There's got to be a way.

Since you see this dialog to confirm admin right:

The icon gives the idea that a shell command is being executed with elevated rights.

So I tested this with osascript (AppleScript) again in Lazarus (uses the unit process).
One button to create the director and one to remove it (including content):

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls
  , process;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private

  public

  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var
  s:AnsiString;
begin
  RunCommand('osascript',['-e', 'do shell script "mkdir ''/Library/Application Support/Test''" with administrator privileges'],s);
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  s:AnsiString;
begin
  RunCommand('osascript',['-e', 'do shell script "rm -rf ''/Library/Application Support/Test''" with administrator privileges'],s);
end;

end.   

This works just fine ... requests a admin password of course. This way we may be able to call a standard Lazarus application as well and run it with elevated privileges. 

So I created a simple program (not an .app bundle!) that creates a directory /Library/Application Support/Test2 ... this of course fails when started normal.
However if I start it like this, it DOES work (and asks permission only once) from Terminal.

osascript -e 'do shell script "./simple" with administrator privileges'

So we could try having our main program start hidden, and use runcommand to tell osascript to start the application with elevated rights.
I think this may very well work ... or not ... my initial test seems to fail, but ... we do see a familiar icon in the authentication dialog ...
Maybe you'd like to do some testing with that.

Conclusion so far: 

• AppleScript can be executed with elevated rights, even from Lazarus with RunCommand. Each script we start will ask for authentication though.
• Lazarus applications that use Cocoa can be started with elevated rights from Terminal.
• Starting that same application with osascript from another application (made with Lazarus) then it seems to fail (Console gives a hint that the called application then actually crashes?)

On that note: I'm not sure what you'd like to do with these elevated applications.
Meaning: just write a config file? Or more complex things?

I did read your project saying "Build an example in Lazarus for macOS which elevates itself upon launch using the AuthorizationExecuteWithPrivileges API.".
However, I do not think an application can elevate itself any more (with the security changes done by Apple in the last 2 big OS changes - as of Big Sur I believe).
Whichever solution we're looking at, would be a secondary program or script started by the main application, for example like I did with osascript.

Anyhoo ... just a curiosity question: what kind of company are you running ... (SF based right?)
Maybe we can help each other (if interested; better discussed by email of course 😉 ).

Posted by: @hans

Since you see this dialog to confirm admin right:

Attachment : image.png

The icon gives the idea that a shell command is being executed with elevated rights.

So I tested this with osascript (AppleScript) again in Lazarus (uses the unit process).
One button to create the director and one to remove it (including content):

unit Unit1;

{$mode objfpc}{$H+}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls
  , process;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    Button2: TButton;
    procedure Button1Click(Sender: TObject);
    procedure Button2Click(Sender: TObject);
  private

  public

  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var
  s:AnsiString;
begin
  RunCommand('osascript',['-e', 'do shell script "mkdir ''/Library/Application Support/Test''" with administrator privileges'],s);
end;

procedure TForm1.Button2Click(Sender: TObject);
var
  s:AnsiString;
begin
  RunCommand('osascript',['-e', 'do shell script "rm -rf ''/Library/Application Support/Test''" with administrator privileges'],s);
end;

end.   

 

This works just fine ... requests a admin password of course. This way we may be able to call a standard Lazarus application as well and run it with elevated privileges. 

So I created a simple program (not an .app bundle!) that creates a directory /Library/Application Support/Test2 ... this of course fails when started normal.
However if I start it like this, it DOES work (and asks permission only once) from Terminal.

osascript -e 'do shell script "./simple" with administrator privileges'

 

So we could try having our main program start hidden, and use runcommand to tell osascript to start the application with elevated rights.
I think this may very well work ... or not ... my initial test seems to fail, but ... we do see a familiar icon in the authentication dialog ...
Maybe you'd like to do some testing with that.

Attachment : image.png

 

Conclusion so far: 

• AppleScript can be executed with elevated rights, even from Lazarus with RunCommand. Each script we start will ask for authentication though.
• Lazarus applications that use Cocoa can be started with elevated rights from Terminal.
• Starting that same application with osascript from another application (made with Lazarus) then it seems to fail (Console gives a hint that the called application then actually crashes?)

 

On that note: I'm not sure what you'd like to do with these elevated applications.
Meaning: just write a config file? Or more complex things?

I haven't yet had a chance to look at this in the implementation stage, but should be able to do so later today.

Looks very promising!

There's still one dead giveaway though:

Our version says "osascript wants to make changes".

Their version says "whatever I have named my application wants to make changes".

We are getting extremely close, in figuring out what they are doing and how they are doing it.

How do you think are they able to manage to display the correct application name in the elevation dialog?

Posted by: @hans

I did read your project saying "Build an example in Lazarus for macOS which elevates itself upon launch using the AuthorizationExecuteWithPrivileges API.".
However, I do not think an application can elevate itself any more (with the security changes done by Apple in the last 2 big OS changes - as of Big Sur I believe).
Whichever solution we're looking at, would be a secondary program or script started by the main application, for example like I did with osascript.

Anyhoo ... just a curiosity question: what kind of company are you running ... (SF based right?)
Maybe we can help each other (if interested; better discussed by email of course 😉 ).

As you know, the project I tested with VMware InstallBuilder was on Monterey 12.4, and they still have a way in which they have managed to get it to work.

What a puzzle, right?

A thrilling challenge to figure this out, with such limited documentation and of course, no official support!

Regarding your other point of curiosity, I will follow up by DM right away!

Oh yes indeed a challenge ... I've been fighting with this for several years already (ApplePi-Baker).

Silly option: rename a copy of the binary osascript to whateverwewant ?
And yes ... that worked ...

I just copied osascript (/usr/bin/osascript) and renamed it to "whateverwewant" and there it is ...

Not sure if this is something e can copy and execute on another Mac though.

However ... this feels a little hacky, and I would love to find the correct way to do this. 😊 
But the lack of documentation is a problem for sure.

Posted by: @hans

Oh yes indeed a challenge ... I've been fighting with this for several years already (ApplePi-Baker).

Silly option: rename a copy of the binary osascript to whateverwewant ?
And yes ... that worked ...

Attachment : image.png

I just copied osascript (/usr/bin/osascript) and renamed it to "whateverwewant" and there it is ...

Not sure if this is something e can copy and execute on another Mac though.

However ... this feels a little hacky, and I would love to find the correct way to do this. 😊 
But the lack of documentation is a problem for sure.

Haha! I had thought of that and wondered if it would work. You could then rename it Apple or macOS or whatever you like and it would still fly :) Some security, isn't it? All this stuff, when insensibly implemented, just makes life harder for everybody trying to do things legitimately - and serves no real deterrent purpose to anyone else.

Totally 1000% off topic, but the whole Pegasus spyware thing is a great showcase. Some company collects zero-days, probably at terrific cost to the mental health of the people doing the actual collection. In the meanwhile, we see Apple's apartment-sized billboards in San Francisco, advertising that iPhone is the one and only choice for privacy. Ha! Then Pegasus makes some money and some democratic activists somewhere on the globe suddenly find themselves in jail. Great job, Apple! Haha. 

Some security indeed 🤣 
I think in the end Apple's ideas aren't the worst on the planet. Things would be easier though if Apple would provide easier to use API's (and documentation) and tools.
I know the Windows platform is a mess, but "fixing" my application to accommodate Apple's requirements is making me a little tired of continuing free software development.

As with all stuff: no way we can get everything 100% fool proof.
We know this already for a few decades ... and the punishment for cybercrime is a joke as well.
So this will be an ever lasting loop ... Pegasus included haha  😉 

Very well said!

I would normally dare say the Windows side of things is generally better documented, but I've seen Microsoft lose even lawsuits (almost two decades ago) about APIs that they left intentionally undocumented - so yes, in my view, they're all as bad as the other.

If DoJ had broken up Microsoft (we have Florida to thank for electing Bush, starting the Iraqi war, causing global warming, and for cancelling the breakup of Microsoft too) the whole industry might have been at a different place. But I digress - so please do forgive me for having inadvertently hijacked this thread with entirely unrelated stuff! I'll go ahead and shut up now :)

Just replied to your private email too!

BTW, what happens if osascript or similar are missing on the target system?

Would Apple's SIP guarantee their availability somehow?

Actually another interesting test could be to mess with osascript and see if that breaks VMware InstallBuilder at all...

(I'll reply to your email in a little bit - lots to read, more coffee needed 😉 )

I assume that osascript will always be available. I have yet to see a Mac without it (running OSX) as far as I know.
I'm not even sure if it would matter, since we'd bring our own copy of osascript?

I guess, in all my research, test etc, I have found so far that:

1. ExecuteWithPrivileges relates to elevating "other" applications/binaries (binaries we call, for example: call mkdir to make a directory).
2. Applications cannot elevate themselves.
3. Helper tools can be used by applications to execute specific tasks with elevated privileges (requires signing and proper plists).
4. osascript can used for this (and even renamed)

I did some more testing, and have come to a halt with this code - which fails(!), but should be pretty close to what "AuthorizationExecuteWithPrivileges" should look like:

unit Unit1;

{$mode objfpc}{$H+}
{$modeswitch objectivec1}
{$linkframework Security}

interface

uses
  Classes, SysUtils, Forms, Controls, Graphics, Dialogs, StdCtrls, MacOSAll;

type

  { TForm1 }

  TForm1 = class(TForm)
    Button1: TButton;
    procedure Button1Click(Sender: TObject);
  private

  public

  end;

var
  Form1: TForm1;

implementation

{$R *.lfm}

{ TForm1 }

procedure TForm1.Button1Click(Sender: TObject);
var
  status:OSStatus;
  authRef: AuthorizationRef;
  authFlags: AuthorizationFlags;
  authRights: AuthorizationRights;
  authItem: AuthorizationItem;
  pipe: UnivPtr;
  arguments: Arg10000TypePtr;
begin
  authItem.flags := 0;
  authItem.name  := kAuthorizationRightExecute;
  authItem.value := nil;
  authItem.valueLength:= 0;

  authRights.count := 1;
  authRights.items := @authItem;

  authRef   := nil;
  authFlags := kAuthorizationFlagInteractionAllowed or kAuthorizationFlagExtendRights or kAuthorizationFlagPreAuthorize;
  status    := AuthorizationCreate(@authRights, kAuthorizationEmptyEnvironment, authFlags, authRef);

  arguments := nil;
  pipe      := nil;

  if status=errAuthorizationSuccess then
    status := AuthorizationExecuteWithPrivileges(authRef,'/bin/mkdir "/Library/Application Support/Banana"',kAuthorizationFlagDefaults,arguments,pipe);

  ShowMessage(BoolToStr(status=errAuthorizationSuccess,'OK','FAIL')+' '+IntToStr(status));
end;

end.

Example in ObjC: (source)
(you could use it maybe as a bootstrap maybe?)

/*
 * OSXSimpleAuth.m
 *
 * Created by Michael V. O'Brien on 02/07/2009.
 *
 * This code was written to show how to use
 * AuthorizationExecuteWithPrivileges in a simple and straightforward
 * example.  It is probably not secure, but it gets the job done for
 * demonstration purposes. Look at OSXSlightlyBetterAuth example for
 * more details.
 */


#import <Foundation/Foundation.h>
// Add Security.framework to the Xcode project

int main (int argc, const char * argv[]) {
    NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
	
    // Create authorization reference
    AuthorizationRef authorizationRef;
    OSStatus status;
	
    status = AuthorizationCreate(NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authorizationRef);
	
    // Run the tool using the authorization reference
    char *tool = "/sbin/dmesg";
    char *args[] = {NULL};
    FILE *pipe = NULL;
	
    status = AuthorizationExecuteWithPrivileges(authorizationRef, tool, kAuthorizationFlagDefaults, args, &pipe);
	
    // Print to standard output
    char readBuffer[128];
    if (status == errAuthorizationSuccess) {
        for (;;) {
            int bytesRead = read(fileno(pipe), readBuffer, sizeof(readBuffer));
            if (bytesRead < 1) break;
            write(fileno(stdout), readBuffer, bytesRead);
        }
    } else {
        NSLog(@"Authorization Result Code: %d", status);
    }
	
    [pool drain];
    return 0;
}

So bringing our own copy of osascript: Is this file not versioned, doesn't it have dependencies on OS libraries which might be version sensitive (just thinking about how things happen in olden Windows land), and thus wouldn't it be dangerous to bundle it? Apple does have reasonably decent SIP though (unless manually disabled of course), so I suppose based on your answer to the preceding, it might be better to just invoke it rather than to bundle it.

Re: Apps being unable to elevate themselves - OK, so how about we elevate some other helper-ish app, which then just reverse invokes its own elevator in now-elevated mode? That might fly, no?

Re: Sample - perfect! This is just what I am looking for. However are you saying it doesn't work in Lazarus but works in Xcode (or fails in both)?

Last but not least - surely the most legitimate approach is the helper tool, but the signing/notarization/etc. on that is extremely burdensome - if only because we've already seen VMware InstallBuilder able to do it without any of that. Maybe they are running osascript and then reverse invoking themselves, can we say that is the best working theory we have so far?

I just tried the latest Lazarus sample. As you know it seems to work beautifully until it doesn't. The error result is:

errAuthorizationToolExecuteFailure = -60031

Wow really! If I remove the parameters to the mkdir command line tool, the result turns into success.

Oh wow seriously? What happens if I pass ParamStr(0) instead?

It works, yaaay!