+19
Started

Sign macOS app

Alex Hart 3 months ago • updated by Tom R 2 days ago 63 1 duplicate

In order to deploy macOS privacy preferences policy via MDM/DEP, the macOS app in Mojave that needs exceptions must be signed. Otherwise, a user has to create exceptions to allow remote control via ConnectWise Control, which isn't ideal. I don't want to have to sign your app to get the payload pushed out to create the exceptions from our management software. If you signed your apps like other developers, this would be much easier for all users, like those of the Addigy and JAMF communities. 

Available in Version:

Duplicates 1

+1

I just did a fresh install of 6.9.20424.6863 and tried to setup a Privacy Preferences Policy Control whitelist payload, but the /opt/screenconnect-XXXXXXXXXX.app is still coming back as not signed. Here's what I'm seeing:

$ codesign -dv /opt/screenconnect-XXXXXXXXXX.app/
/opt/screenconnect-XXXXXXXXXX.app/: code object is not signed at all

vs:

$ codesign -dv /Applications/iTerm.app
Executable=/Applications/iTerm.app/Contents/MacOS/iTerm2
Identifier=com.googlecode.iterm2
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=79381 flags=0x0(none) hashes=2473+5 location=embedded
Signature size=4620
Signed Time=Nov 11, 2018 at 2:49:13 PM
Info.plist entries=47
TeamIdentifier=H7V7XYVQ7D
Sealed Resources version=2 rules=13 files=153
Internal requirements count=1 size=216
+1

Without signing, supporting this en masse is costing a lot of support hours.

-2

Apple’s recent release of the Mojave operating system introduces new features and security measures, offering end users more peace of mind but also introducing new challenges to partners supporting Apple machines. The team at ConnectWise Control is working to ensure that these changes have the least amount of impact possible for partners.

These new security and privacy settings were enacted by Apple and change how all vendors of remote control products are able to deploy to endpoints. One of these new challenges is a change in the way hosts gain control of Mojave devices. When first connecting to a macOS Mojave session, end users must physically allow access to the ConnectWise Control app from the machine itself. The steps to control a macOS Mojave session have been outlined in documentation. After extensive research, the team has determined that this requirement is mandatory on the first connection; signing the application or access agent will not solve this issue.

ConnectWise Control is actively researching the best way to manage the Gatekeeper feature and improve the experience when updating or reinstalling an access agent on macOS Mojave. The team has also planned performance enhancements and improvements to the Mac client, and will communicate more Mojave updates as they become available.

+2

@Caitlin signing the product will fix the problem. Then it can get access to accessibility through an MDM like other applications 

So, if end users do not have admin rights on their machines, what then? 

+1

To add some background to this, we're increasingly seeing our customers moving towards mixed / MacOS workstations, and supporting MacOS for BYOD.  We LOVE ScreenConnect and don't want to replace it - but we need something that will work reliably and easily on MacOS including ad-hoc sessions.  The current situation with signing etc is not good, but if it is going to get worse then we might have to look for another solution even though we REALLY don't want to.  I don't know enough to contribute anything technical on this, but I want to plead with you to really exhaust EVERY option - imagine if you're the only remote control solution to crack this one... that's a unique selling point right there!

+1

@Alex Heylin they won’t be the first. This can already be done for Team Viewer, bomgar and I believe Logmein


https://www.jamf.com/jamf-nation/discussions/29703/allow-apps-in-security-privacy-privacy-accessibility-in-mojave-bomgar


Thanks @A Simm, in which case it clearly CAN be done, and we need it to be done. The company (we already use) that we consider a direct competitor to LT uses LMI, and while we don't want to use them instead of LT - this is another nail in the coffin for LT / SC having a place in our business. 

It's been standard practice to sign MacOS packages for years now. So, why not just do it? Please don't let this turn into a dev versus product fight. Side with the customers and do the right thing. Just take the devs out for beers. 

+2

I tried posting this as a reply above, but it has been stuck in moderation for 2 days now. I'll try here instead. 

Hi Caitlin (and team),

I'd like to encourage your team to not give up. I respectfully reject your assertions that this isn't possible. I know this is in fact possible, as I've seen it working (with other applications and with your application when signed). Your team unfortunately did not research extensively enough.  While I agree signing the application in and of itself not enough, if you have an Apple MDM setup and deploy your own privacy policy that whitelists the application (a signed application is required), then you can remotely approve the use of CW Control *without* any user intervention on the first connection. Let me try to help by providing some reading material:

https://derflounder.wordpress.com/2018/08/31/creating-privacy-preferences-policy-control-profiles-for-macos/

https://www.jamf.com/jamf-nation/articles/553/preparing-your-organization-for-user-data-protections-on-macos-10-14

https://macadmins.herokuapp.com/ (see mdm channel)

https://github.com/carlashley/tccprofile

I'd love to work with you and your team more directly to make sure this comes to light. If that is at all helpful, please don't hesitate to contact me. Here are the signing requests:

https://control.product.connectwise.com/communities/6/topics/1974-complicated-process-required-to-control-macos-1014-mojave-clients

https://control.product.connectwise.com/communities/6/topics/2014-mac-signed-application

Please note, this is the .app that needs to be signed, not the installer. 

Thank you for considering my feedback on this.

I almost lost a client because of this. They sent me an email about how it costs $100 to become a developer, how can we use this software, etc etc. It made me reconsider using CW Control.

Also, another user was able to get this working (only if they have a developer cert from Apple and sign the app themselves, which shouldn't be a requirement, hence this topic):

https://control.product.connectwise.com/communities/6/topics/1974-complicated-process-required-to-control-macos-1014-mojave-clients#comment-6782

+1

I wanted to give an update on our ongoing work with Mojave. Thanks for your continued suggestions and attention. ConnectWise Control is multi-instance, not multi-tenant like other remote control solutions, which means that changes to compensate for Mojave permission updates are a higher architectural discussion, and something we’re diligently researching. Being a multi-instance product provides additional levels of security for our partners, but also presents new challenges. 

+2

I enjoy all the feedback we have gotten on this issue. As we continue development on this issue, I wanted to provide some clarification.

We have started development on signing the macOS installer bundle. When the macOS installer bundle is downloaded, it undergoes dynamic changes related to our customization features. The same is true for all of the installers. However, only for macOS do these changes break the signature of the bundle. Therefore, not signing the application was a tradeoff to allow for the .pkg to have customized branding, naming, etc. However, the release of Mojave changes that calculation for the following reason: permissions granted to unsigned applications to not persist upon reinstall.This is the main reason why we have decided to investigate signing the installer. Doing so requires some significant changes to what/how we customize our application, but we are working hard to maintain all functionality at this point. This is the main sticking point with signing the application.

As Caitlin said, this does not solve this issue because end users will still be required to be admin users and supply permissions to our application. Although signing the application allows it to be distributed with an MDM product, we do not consider that a solution because we can't require our partners to purchase a 3rd-party tool to support ours. Currently, there is no way to get around these permission challenges for any software vendor. That said, we are glad that signing our application has the ancillary benefit of making it compatible with 3rd-party tools in use by our partners.

Hope that helps. We will keep this thread updated as work progresses.

Is there an ETA of when this will be working for macOS 10.14? Currently unable to push it out to labs until I can give accessibility access using an MDM.

+1

You can expect this change to be available in the next stable version of 6.9, or the pre-release of 7.0, before the end of January

Please post here when that version is available.  While I can also dig up the Team ID after it is installed, can you also provide us the Team ID of your signed installer when the new version is available?  This will make it possible to whitelist in Jamf/PPPC before I test the new version.

Thanks!

You should whitelist these Team IDs:

X5ZCVVHK4S

K8M3XDZV9Y

+1

We need more than just team IDs. Here's a sample of code requirement needed to create a configuration profile to whitelist an app. Note that the team ID is at the end, and there is information related to the certificate that is attached to the Jamf agent. Since Screen Connect has no certificate there's not enough information to put into the code requirement field.

identifier "com.jamfsoftware.jamfAgent" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = "483DWKW443"

The next Stable release of 6.9 after you made this post came and went without any change to the situation, I suspect the code for that release was locked already.

Do you have an eta for the NEXT 6.9 stable that will have this in, or pre-release of 7 ?


This is critical for us and we are getting a lot of backlash denying upgrade to Mojave while we wait for this, i'd love to get this tested ASAP.


Thanks 

Brandon

The latest stable version of 6.9 came out a few days after you made this post and the change was not there, I assume the code was already "Locked" by that time.

When will the next stable version of 6.9 with this fix in it be available ? Or a Pre-Release of 7 ?


We are getting masses of flack from our user base because we wont allow them to have Mojave until this is fixed and we can control their machines properly.

I would love to know exactly why ConnectWise was not signing the app in the first place. I have WASTED hours of precious time working on a profile that would allow Screen Connect to run, and then I find out that because it's not signed, this is not possible. Application signing became a requirement on the Mac with the release of OS X Lion nearly 8 years ago. Why did ConnectWise wait so long? When I have a choice, I won't work with developers who don't sign their work.

Only the macOS access client is not signed. This is due to incompatibilities with Apple's signatures and Control's customization features. The unsigned access client has not caused any problems on macOS until Mojave. 

OK. So it's Apple's fault for improving the security of their operating system. Let me go on record as saying that I do not blame Apple for this. I am 100% in support of their security and privacy measures on macOS even though they are sometimes a pain to have to deal with. As I stated before in this thread, macOS Mojave was released to developers in June of last year. The full release of the OS was released in late September. 

The macOS access client currently works as expected when permissions are granted. The main issue is that the applications permissions are not persisted upon reinstall, and must be re-granted. We are working to remedy this and are testing OS releases more thoroughly in the future to find issues like this sooner.

Right. It will work once permissions are granted, but that requires admin access. If a user is not an admin, they can't grant permission. Also, a lot of the affected systems are out of my reach. I cannot grant access. The only solution to this is that we need the app to be signed. Period. I don't care about the installer. When Jamf Pro runs the installer for Screen Connect, it does so with root privileges, so there is no Gatekeeper warning. The app itself needs a developer certificate. I'm not going to debate this. We know what the solution needs to be, so it needs to be implemented.

Brandon, can you please clarify what it is that ConnectWise is working on (referenced above in https://control.product.connectwise.com/communities/1/topics/2046-sign-macos-app#comment-7007 "You can expect this change to be available in the next stable version of 6.9, or the pre-release of 7.0, before the end of January")? I really hope that the app itself is going to be signed as part of that work, which is what this ticket is for, and not something else. I would expect that the customizations are either held outside the application (in Library or something like most other apps). I could see you signing before download (after customizations are injected server-side), but it seems easier to just move those outside the .app that you sign. Ideally, you aren't signing with any client preference changes on the server side (that requires re-install of client. Bottomline, this request and the outcome of any related work should be a signed app. 

The changes include signing the macos access client. Please refer to my comment above for a description of what's involved with that.

Our customization features include rebranding of the application that is a part of the app itself and cannot be extracted to an external library (e.g. bundle name, icon, etc)

Don't forget that the privacy permissions manually granted are reset anytime you update the client, which you guys also do very frequently, for better or worse.

Good point, because an update to the client requires a reinstall, the clients permissions will not persist. 

If it will help, I would be happy to test the new version by distributing it using one of our Jamf Pro servers. We need to be able to deploy Screen Connect without users being nagged about approving the app. A lot of the Macs that we manage never get touched by us. Some of them are as far as 1000 miles away, and the users are not admin users. The key for us being able to whitelist the app is that it must be signed. There is no other way for us to do this.

There really shouldn't be much to test. They just codesign the app and we put the Code Requirement string in our PPPC profiles. 

No. I test. When I took my Jamf certification courses, I was taught to test, test, test, and do more testing before deploying something to hundreds or thousands of systems.

@Headbolt: There is a new version of 6.9 available in the Canary channel in Control Cloud (6.9.21870.6964). This includes several fixes for macOS Mojave (including the signing of the access client) and is currently in testing.

!!!!NOTE: Versions in the Canary channel have not completed internal testing and are not appropriate for production environments!!!!

A new version of 6.9 will be available in the Preview channel once testing is complete. I will keep this thread updated with details.

+2

This version (6.9.21870.6964) is now available in the Control Cloud Preview channel. Barring setbacks, this version should be able to be made stable next week.

-1

Does this version include the signing fix? Do we have an idea what day it will be made stable ?

+1

Have a Free Cloud account that is seemingly on that version now, have tested with that and created a Config Profile to deal with the TCC issue.

Seems to work.

Will re-test when This release goes stable and we have updated our live install

+1

FYI for those that need it, here are the settings i use to allow the TCC/PPPC to work.

The Client ID does not seem to be an issue, so this should work for anyone on the new version.


I do mine in JAMF

APP

Identifier

com.screenconnect.client.access

Bundle ID

Code Requirement

identifier "com.screenconnect.client.access" and anchor apple generic and certificate 1[field.1.2.840.113635.100.6.2.6] /* exists */ and certificate leaf[field.1.2.840.113635.100.6.1.13] /* exists */ and certificate leaf[subject.OU] = K8M3XDZV9Y


APP or Service

Accessibility


AppleEvents

        Reciever Identifier

        com.apple.systemevents

        Bundle ID

        Reciever Code Requirements

        identifier "com.apple.systemevents" and anchor apple


You should also be including /bin/bash in accessibility and appleevents

UPDATE: There have been no major error reports received from Cloud Preview partners about 6.9.21870.6964. This pre-release is available to on-prem partners through the ConnectWise Control downloads page (https://www.connectwise.com/software/control/download). It will hopefully be upgraded to stable next week.

That page shows "there are no pre-release versions available at this time."

Any word on when this will got to stable and be available to cloud customers? I can sign my customized app and set the appropriate PPPC settings via my MDM which allows the app to launch but every time an update (and subsequent reinstall) of the app comes out this breaks the code signing and is very annoying.

Should be in the next few days. We are soliciting more feedback on the build from Cloud preview partners before we declare it stable. The more partners that participate in the preview channel, the faster we can graduate builds to stable.

v6.9.21870.6964 has been promoted to stable and is available for on-prem and cloud partners. This thread should remain open while documentation is being completed.

I just built a custom branded pkg installer (10:25 am EST 2/14/2019) from our Cloud Portal and it installed 6.9.21691.6956

Is the cloud installer only available for direct download as of now rather than through our portal?

Also will the pkg installer also be code signed now as it is not currently?

Also it is currently only listed for download at https://www.screenconnect.com/Download?result=5sdfss156d156sfsd156fsd156f

and not

https://www.connectwise.com/software/control/download

Can we have some continuity?

  • Verify that your cloud instance has been upgraded to 6.9.21870.6964. Every client installer is downloaded from a particular instance
  • The pkg access client is signed
  • You are able to download 6.9.21870.6964 stable from https://www.connectwise.com/software/control/download 

To clarify, the pkg itself is not signed, but the app it installs is. I don't believe we have any imminent plans to sign the pkg itself

Thank you. There is am issue with our license that is preventing your cloud instance from upgrading. I will get that resolved internally. The link you provided now shows 6.9.21870.6964. in pre release NOT stable. It showed neither this morning.

Well that's still a huge mis step on Connectwise's part. It's one additional certificate to sign the package. 

Why would you go through the trouble of signing the app and not the package? What would like me to tell our customers/employees when they receive Gatekeeper warnings which can be very forbidding. And no telling them "its ok to install' is not a valid answer.

Signing the pkg without removing support for customization would be a significant undertaking (though of course you're welcome to create a separate feature request for that if it doesn't already exist).

You could also connect with a support session to begin with and then install the access agent from there; the support bundle is signed, so Gatekeeper shouldn't complain about that.

 6.9.21870.6964 now shows up in stable on the downloads page.

ConnectWiseControl PPPC.mobileconfig

In case anyone needs it, I've attached a .mobileconfig that you can deploy with your approved MDM/DEP solution. 

Here is the outcome of deploying that:

As a heads up if you've signed screen connect with your own developer cert and deployed a PPPC profile this update is probably gonna break that since the app is now signed with Connectwise's cert.

I assume that's self-explanatory and I'm guessing that you may have been impacted unexpectedly. perhaps that is because you have automatic client updates on? If you turn off automatic client updates, then you won't have to worry about this. Simply change out your profile before updating clients. Not only is the cert going to be different, but also the identifiers. The application and changed in this update as well. 

Oh yeah I get it and was expecting it (well not today because Connectwise said our instance would be upgraded next week even though it was today sigh...) but I wanted to make sure other people knew as I don't think Connectwise made that overly clear and it might catch people by surprise.