Tunnelblick install via Munki+Autopkg -

[who...@lygos.com]

Hello,

I am trying to improve Munki and Autopkg support for Tunnelblick by performing all tasks requiring admin privileges at the time of installation. I am basing this work on a previous discussion: https://groups.google.com/forum/#!topic/tunnelblick-discuss/UYeR7vv_rXM. Packages created via Autopkg are sometimes installed onto a different drive than the one booted from, such as when using netboot to perform a clean OS+apps installation onto the local hard drive. Running Tunnelblick.app/Contents/Resources/installer 5 and Tunnelblick.app/Contents/Resources/installer 16 to secure the app and configuration currently fails when Tunnelblick.app is not in /Applications (tested with v3.7.1b and v3.7.2beta03). Would it be possible to remove this limitation so that installer 5/16 can be run with Tunnelblick on a non-boot disk and then when the non-boot disk is moved to a configuration where it is mounted at / (such that Tunnelblick is now in /Applications), Tunnelblick can run without admin privileges?

thanks!

-Will

[Tunnelblick developer]

To make sure I understand: are the problems that Tunnelblick will only or secure the copy of itself on the boot drive and will only install a configuration onto the boot drive, and you want to secure and install to an arbitrary location which is not necessarily on the boot drive?

It will be difficult to change that because the boot drive paths are hard coded into Tunnelblick for security reasons. Adding the ability to specify target paths would add complexity.

Assuming that Munki can deal with macOS Installer packages, I think it makes more sense to create such a package for Tunnelblick, instead of running Tunnelblick's installer program.

It shouldn't be difficult to make such a package; you could install Tunnelblick and the configurations on a "clean" system, and then copy from various places on that system (/Applications/Tunnelblick.app, /Library/Application Support/Tunnelblick, ~/Library/Application Support/Tunnelblick, ~/Library/Preferences/net.tunnelblick.tunnelblick.plist come to mind but there may be others) into the Installer package, preserving ownership and permissions. That way you wouldn't have to do anything when Tunnelblick changes except recreate the Installer.

You should see https://groups.google.com/forum/#!topic/tunnelblick-discuss/ek2y6ywHj8s, too, which points out that Tunnelblick's built-in update mechanism requires a computer admin username/password.

[who...@lygos.com]

Yes, your understanding of the issue is correct. I can make a package as you suggest, I was just hoping to not duplicate the already existing functionality of the installer. 

I did notice the hard coded paths when looking through the Tunnelblick source code. I believe some of the documentation related to this is outdated or incorrect. 

https://tunnelblick.net/cFileLocations.html states:

"The Tunnelblick application, Tunnelblick.app, is usually stored in /Applications on the startup volume. However, it may be located anywhere on any volume whose filesystem has appropriate security support. In general, that means any local hard drive. For security reasons, Tunnelblick can only run from a volume whose filesystem supports 'suid'."

-Will

[Tunnelblick developer]

Thanks for pointing out the out-of-date information on the File Locations page. I have fixed that.

A GitHub "pull request" that creates a Tunnelblick installer package would be welcome if it does not requre third-party tools. It could be written as a separate build phase, or as a routine in, or separate script called by, Tunnelblick's "BuildAppsAndDmgs.sh" script. It would use an unsigned copy of Tunnelblick.app (and the kexts); signing them is done as a separate step. (Signing is done as part of the release process, not part of the build process. The release process might then have to duplicate that work to create a signed installer and/or a signed installer that contains a signed application.)