Re: [tunnelblick-discuss] Firstrun without administrative rights?

[Jonathan K. Bullard]

It might be possible, but it probably isn't easy.

Tunnelblick needs administrator rights so it can secure itself and create a suid binary which runs as root to do certain things (such as start OpenVPN) that require elevated access.

The "installer" program, within Tunnelblick.app/Contents/Resources/installer, is what Tunnelblick uses to install and secure itself. It might be possible to run the installer via sudo, but in my experience sudo in scripts doesn't work well. But even then, someone has to enter the admin password sometime.

Each time Tunnelblick is launched, it checks to see if has been installed properly (in Applications, with proper ownership/permissions on each of its components.) So if you can put your rebranded Tunnelblick.app in Applications, and set up ownership and permissions properly, it will not know that it didn't do the installation itself, and won't ask for an admin username/password.

The other alternatives would be to write an installer package for Tunnelblick, or a script that copies Tunnelblick to Applications, creates folders and secures them, and sets ownership and permissions.

On Thu, May 30, 2013 at 2:25 PM, <he.ke...@googlemail.com> wrote:

Hello,

i am planning to deploy a rebranded version of Tunnelblick with Munki, the only issue i have so long is that Tunnelblick ask for administrative rights on the first run but none of my standard users have and should have those rights. Is there a way to run those tasks in the moment of the installation via a script?

Regards

Henning

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-dis...@googlegroups.com.
Visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jonathan K. Bullard]

You'll have to look at the source code to see what to pass the installer as arguments. I think you should call it with a single argument which is a decimal number which is interpreted as a binary bitmask. The bits for the mask are INSTALLER_* in defines.h. More description of what happens is in installer.m itself. (In Xcode, installer is in "Other Sources", defines.h is in "Classes/Common".)

If you look at a Console log, Tunnelblick logs the argument the installer is called with, so you can see that.

installer uses two "flag files", too, as I recall, one to indicate it is finished, and one to indicate an error occurred. See the source for details. I think the "finished" file may be created by Tunnelblick itself before starting the installer, but check the source.

Please report back with your results.

On Thu, May 30, 2013 at 2:54 PM, <he.ke...@googlemail.com> wrote:

Thanks for your fast response.

as the installer of Munki runs with administrative privileges i will try to run the "installer" program as a postinstall script, hopefully that will work. I will give a response how it worked out

Regards

Henning

To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-discuss+unsub...@googlegroups.com.

Visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jonathan K. Bullard]

Three things:

1. I don't think you can use sudo to run installer. It thinks the user is root, so it tries to create folders for root. Tunnelblick starts the installer via an OS X executeAuthorized call, which lets installer behave as root or as the user, and switch back and forth.

2. Your command line needs to have a decimal number, not a hex number:

sudo install 4

instead of sudo install 0x0004; or

sudo install 16

instead of sudo install 0x0010

(I just used 4 and 16 to illustrate the hex to decimal conversion; I don't konw what bits in the bitmask they represent and am not saying to use them.)

3. I think what you want to try in Munki is "installer 2" (INSTALLER_COPY_APP, which will copy the app to /Applications and secure it). As I said, it won't work as a sudo, but maybe Munki starts it differently.

On Fri, May 31, 2013 at 4:41 PM, <he.ke...@googlemail.com> wrote:

I tried serval different possibilities but had no success in guessing the right syntax.

a sudo ./installer 0x0004u (in define.h: #define INSTALLER_SECURE_APP            0x0004u) give the following log entry:

APPNAME installer started 2013-05-30 13:53:53. 1 arguments: 0x0000

Unable to create directory /var/root/Library/Application Support/VCCPTunnel with permissions 750

stat of /tmp/tunnelblick-authorized-running failed

Error was 'No such file or directory'

the logentry from the standard firstrun looks like this:

APPNAME installer started 2013-05-30 13:30:53. 1 arguments: 0x0005

of course i also tried the 0x0005 but same result as above ;-)

What i am doing wrong?

Any help is appreciated especially I am a total rookie in terms of interpreting code from an app ;-)

Regards

Henning

To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-discuss+unsubscribe...@googlegroups.com.

Visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
You received this message because you are subscribed to the Google Groups "tunnelblick-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tunnelblick-discuss+unsub...@googlegroups.com.
Visit this group at http://groups.google.com/group/tunnelblick-discuss?hl=en-US.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Jonathan K. Bullard]

The code signing won't break when you use a full, rebranded version, because you build an unsigned version, then add the Deploy folder, then sign the .app that includes the Deploy folder.

There are some problems with code signing, though. If I recall correctly, you have to code sign on Lion to be compatible with 10.5 - 10.8 (that's how Tunnelblick does the signing).

On Fri, May 31, 2013 at 5:29 PM, <he.ke...@googlemail.com> wrote:

Thank for you help again.

you are right sudo won't make the trick and unfortunately munki neither as it is started by a launchd with root privileges.

but looking at the logs of standard successful first run, you can see all needed commands to secure the application. I tried to do this via a script and was quite successful with that. the only side effect was that the code signing broke ;-).

Henning 

[Jonathan K. Bullard]

I don't know what causes that. 

When you install Tunnelblick, it takes the signed copy, modifies the ownership and permissions, and the signature stays valid.

Maybe there's a problem with your signing. What commands are you using to sign it?

On Sun, Jun 2, 2013 at 7:54 AM, <he.ke...@googlemail.com> wrote:

Unfortunately that was exact the way i did this.

I even double checked this again by running codesign --verify /Applications/THEAPP.app before and after I run the following commands:

chown -R 0:0 /Applications/APPNAME.app

chmod 744 /Applications/APPNAME.app/Contents/Resources/atsystemstart

chmod 744 /Applications/APPNAME.app/Contents/Resources/installer

chmod 744 /Applications/APPNAME.app/Contents/Resources/leasewatch

chmod 744 /Applications/APPNAME.app/Contents/Resources/leasewatch3

chmod 744 /Applications/APPNAME.app/Contents/Resources/process-network-changes

chmod 744 /Applications/APPNAME.app/Contents/Resources/standardize-scutil-output

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.route-pre-down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.1.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.1.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.2.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.2.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.3.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.3.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn-down-root.so

chmod 744 /Applications/APPNAME.app/Contents/Resources/openvpn/openvpn-2.3.1/openvpn-down-root.so

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/VCCP.tblk/Contents/Resources/ca.crt

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/VCCP.tblk/Contents/Resources/client.crt

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/VCCP.tblk/Contents/Resources/client.pem

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/VCCP.tblk/Contents/Resources/config.ovpn

chmod 4555 /Applications/APPNAME.app/Contents/Resources/openvpnstart

before the everything was fine as nothing was returned from the command.

after running the commands the codesign returned:

APPNAME.app: a sealed resource is missing or invalid.

In architecture: i386

Henning

[Jonathan K. Bullard]

Hmmm. Tunnelblick codesigns all the binaries, too, first (openvpnstart, atsystemstart, openvpn, etc.). Maybe that's the problem.

(That's what it says to do in the Apple Code Signing Guide.)

On Sun, Jun 2, 2013 at 8:07 AM, <he.ke...@googlemail.com> wrote:

I use : sudo codesign -s "3rd Party Mac Developer Application: CompanyName (XXXXXXXXXXX)" APPNAME.app

[Jonathan K. Bullard]

Ah. So it is the signing of the .tblks (or parts of them) that is the problem. That's why it doesn't show up with the standard Tunnelblicks.

codesign --verify fails when run as the user. Does that mean that OS X itself actually thinks the signature is invalid? In other words, when you try to run the program, does OS X allow it, or warn about it not being signed by an Apple-recognized developer (if you are one). And does OS X allow the program to use a Keychain entry that a prior version, had signed with the same signing authority?

Because otherwise it's a bug in OS X.

If OS X is doing it properly, I can modify Tunnelblick to check the signature as root -- I haven't looked, but I assume right now I check as the user. I think the only thing that Tunnelblick does with an invalid signature is give you a warning which you can ignore.

 

On Sun, Jun 2, 2013 at 4:30 PM, <he.ke...@googlemail.com> wrote:

codesigning the other binaries did not fix the issue.

the problem seams to be in changing the files inside the .tblk to POSIX -rw-------, as by this the normal codesigning can not read the files anymore...

the command: codesign --verify -vv APPNAME.app is claiming that those resources are missing.

if i do a: sudo codesign --verify --vv APPNAME.app the command can read the resources and does not complain.

if a start this app on a 10.8 system i get a dialog from the application itself saying that the code signing is invalid.

any idea?

Regards

Henning

Am Sonntag, 2. Juni 2013 14:17:52 UTC+2 schrieb he.ke...@googlemail.com:

Okay that could be the issue I will give this a try as soon as possible.

thanks again for your fast response

Henning

[Jonathan K. Bullard]

I agree.

I just checked, and Tunnelblick does run codesign as the user. I will modify Tunnelblick to run codesign as root if OS X deals with it properly -- that is, if it allows you to run the program and it lets the program use a different program's Keychain entries as long as they were signed with the same credentials.

If OS X does't then there's no point in Tunnelblick doing it, since you can't really use it if OS X doesn't let you!

So please try it out and let me know.

On Sun, Jun 2, 2013 at 5:28 PM, <he.ke...@googlemail.com> wrote:

Am Sonntag, 2. Juni 2013 23:12:16 UTC+2 schrieb jkbull...gmail.com:

Ah. So it is the signing of the .tblks (or parts of them) that is the problem. That's why it doesn't show up with the standard Tunnelblicks. 

codesign --verify fails when run as the user. Does that mean that OS X itself actually thinks the signature is invalid? In other words, when you try to run the program, does OS X allow it, or warn about it not being signed by an Apple-recognized developer (if you are one). And does OS X allow the program to use a Keychain entry that a prior version, had signed with the same signing authority?

The system is not complaining. Its only the application... 

Because otherwise it's a bug in OS X.

If OS X is doing it properly, I can modify Tunnelblick to check the signature as root -- I haven't looked, but I assume right now I check as the user. I think the only thing that Tunnelblick does with an invalid signature is give you a warning which you can ignore.

Even if my problem is surely a rare issue it would be great if you could find some time to modify the behavior of Tunnelblick is this case. Because telling the users that they should dismiss and not care about a security warning is probably not the wisest advice ;-). 

Regards

Henning

[Jonathan K. Bullard]

I'm sorry I wasn't clear. I will not modify the source code to run codesign as root unless, and until, I know that OS X runs it as root when it (A) checks the signature on install, and (B) checks the signature before allowing access to the Keychain.

You can check both of those with the current Tunnelblick, because Tunnelblick can be run even though it thinks the signature is invalid because it is checking as the user.

Let me know what you find out about the OS X behavior.

On Mon, Jun 3, 2013 at 11:16 AM, <he.ke...@googlemail.com> wrote:

Hi Jonathan,

did you already had a chance to modify the code accordingly? I just had look at the source and the most update Rev is 2402 and i am not really sure if that Rev already includes the changes...

Regards

Henning

Am Sonntag, 2. Juni 2013 23:47:40 UTC+2 schrieb he.ke...@googlemail.com:

Jonathan many thanks for you efforts.

I will give that a try tomorrow.

Best regards

Henning

[Jonathan K. Bullard]

Great. Looks good so far. There is one more check:

Make some minor change to the config.ovpn file (add a comment or something), then create a new app with that config, sign it, copy to /Applications (replacing the existing app), and run your script just as you did before. Then launch it and try to connect. It should be able to use the username/password saved in the Keychain by the different version of the app.

On Mon, Jun 3, 2013 at 1:54 PM, <he.ke...@googlemail.com> wrote:

Okay Jonathan now i got it :-)

Just run the following test:

System is 10.8.3

Deploy the App by simple copying it into Applications with ARD

then I run the following script as root:

#!/bin/sh

#

chown -R 0:0 /Applications/APPNAME.app

chmod 744 /Applications/APPNAME.app/Contents/Resources/atsystemstart

chmod 744 /Applications/APPNAME.app/Contents/Resources/installer

chmod 744 /Applications/APPNAME.app/Contents/Resources/leasewatch

chmod 744 /Applications/APPNAME.app/Contents/Resources/leasewatch3

chmod 744 /Applications/APPNAME.app/Contents/Resources/process-network-changes

chmod 744 /Applications/APPNAME.app/Contents/Resources/standardize-scutil-output

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.route-pre-down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.1.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.1.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.2.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.2.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.3.up.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/client.3.down.tunnelblick.sh

chmod 744 /Applications/APPNAME.app/Contents/Resources/openvpn/openvpn-2.2.1/openvpn-down-root.so

chmod 744 /Applications/APPNAME.app/Contents/Resources/openvpn/openvpn-2.3.1/openvpn-down-root.so

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/ca.crt

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/client.crt

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/client.pem

chmod 600 /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/config.ovpn

chmod 4555 /Applications/APPNAME.app/Contents/Resources/openvpnstart

mkdir -p /Library/Application\ Support/APPNAME/Logs

mkdir -p /Library/Application\ Support/APPNAME/Shared

mkdir -p /Library/Application\ Support/APPNAME/Users

chown -R 0:0 /Library/Application\ Support/APPNAME

chmod -R 755 /Library/Application\ Support/APPNAME

chmod 750 /Library/Application\ Support/APPNAME/Users

checking codesigning as user:

mbp15:tmp admin$ codesign --verify -vv /Applications/APPNAME.app

/Applications/APPNAME.app: a sealed resource is missing or invalid

In architecture: i386

resource missing: /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/client.crt

resource missing: /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/ca.crt

resource missing: /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/client.pem

resource missing: /Applications/APPNAME.app/Contents/Resources/Deploy/COMPANY.tblk/Contents/Resources/config.ovpn

checking code signing as root

mbp15:tmp admin$ sudo !!

sudo codesign --verify -vv /Applications/APPNAME.app

Password:

/Applications/APPNAME.app: valid on disk

/Applications/APPNAME.app: satisfies its Designated Requirement

mbp15:tmp admin$ 

Starting the application gives repetitively  the warning dialog from the application that the codesigning is invalid but none from the system. I then started a connecting, entered the credentials and checked the box for storing those in the Keychain.

After this I ended the connection and restarted the computer and started another try and the credentials were taken from the Keychain.... :-)

Sounds like an success, right?

Should I check some more??

Regards

Henning

[Jonathan K. Bullard]

Perfect. Good to know that OS X does it correctly. I will update the source code to have Tunnelblick run codesign -v as root. I will post an update to this thread when I have committed the change.

On Mon, Jun 3, 2013 at 2:32 PM, <he.ke...@googlemail.com> wrote:

Running the update test by adding "# added for update check" to the .ovpn file worked like charm. 

The updated application had still access to the credentials in the keychain.

Regards

Henning

adding "# added for update check" to the .ovpn file

[jkbull...gmail.com]

I have updated the source code (r2405) to run codesign as root for Deployed versions of Tunnelblick.

Note: The signature is not checked while a Deployed version of Tunnelblick is being installed (see comments in MenuController hasValidSignature method), but is checked each time an installed copy is run.

[tac...@gmail.com]

Henning,

Is this script something you'd be willing to share? Automating the install/secure part via munki postinstall script would be really nice.

tack

On Friday, May 31, 2013 2:29:59 PM UTC-7, Henning Kessler wrote:

Thank for you help again.

you are right sudo won't make the trick and unfortunately munki neither as it is started by a launchd with root privileges.

but looking at the logs of standard successful first run, you can see all needed commands to secure the application. I tried to do this via a script and was quite successful with that. the only side effect was that the code signing broke ;-).

Henning 

Am Freitag, 31. Mai 2013 23:03:30 UTC+2 schrieb jkbull...gmail.com: