Notarization Processor?

[Tom Bridge]

Hi all,

With the impending requirement that 3rd party Developer ID-signed software also be notarized, is there a Notarization Check Processor in discussion or development to check the notarization ticket of downloaded items?

Best,

Tom

[Gregory Neagle]

Signing and notarization still does not appear to be required for software distributed and installed by tools like Munki and Jamf. Of course that could change in the future.

Such a processor would definitely be possible -- see the work being done here: https://github.com/munki/munki-pkg/pull/42

-Greg

[Gregory Neagle]

Some other things that occur to me:

The primary use of AutoPkg is to download third-party software, potentially repackage it, and import it into a software distribution mechanism like Munki or Jamf.

Software distributed via mechanisms like Munki or Jamf does not trigger Gatekeeper mechanisms, either during install or first launch, so signing and notarization is of less use.

I also wonder about the ramifications of notarizing software that isn't _yours_ -- IOW, software that is signed with a third-party vendor's cert, wrapped in a package signed with _your_ cert, and then submitted for notarization...

-Greg

[Erik Gomez]

I actually worry about that with munki.

What happens if someone signs their munki package and uploads it for notarization, then later someone does the same thing?

I have a feeling this will be an edge case Apple hasn't thought about.

Thanks,

Erik Gomez

 

---

From: 'Gregory Neagle' via autopkg-discuss <autopkg...@googlegroups.com>
Sent: Monday, June 17, 2019 10:06 AM
To: autopkg...@googlegroups.com
Subject: Re: [autopkg-discuss] Notarization Processor?

 

--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to autopkg-discu...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/4FC31F58-06A8-41F8-BD5B-A3AF2D994A4A%40mac.com.
For more options, visit https://groups.google.com/d/optout.

[Gregory Neagle]

I don't think Apple's given much thought to the distribution of open source software at all.

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/BN6PR15MB1860DDF1BB178D6829AC66F2A3EB0%40BN6PR15MB1860.namprd15.prod.outlook.com.

[Tom Bridge]

The way I understand signing and notarization - which is, admittedly, from outside of Apple’s hierarchy and decision-making process - is that when you sign munki at the time of build, your version submitted for notarization is unique to the signing process. That would mean my version, signed with a Technolutionary Developer Application ID certificate, would be different and independent from a version signed by another Developer ID Application certificate. 

Apple has not made public what the notary service is scanning for, so we can’t know how it would interpret the submission of similar binaries from multiple different organizations. I can certainly envision a world in which that would trigger a security inspection, but that’s not a guarantee either. 

I would imagine, though, that the notarization result of my submission would match the results of the other submissions with different IDs, as scans like this should be idempotent. 

For those of you with AppleCare Enterprise Alliance subscriptions, would you be willing to submit this as a ticket for exploration? I’m afraid I left my $50,000 in my other trousers. 

With regards to my original request, I’m hoping to catch a couple of circumstances:

1) Downloaded item is signed but fails a stapler verify action - in which case I’d like to see AutoPkg attempt to staple the ticket, or note that the stapler staple action fails. Goal: identify which developer we need to encourage to not just submit for notarization, but staple the ticket to the distribution method.

2) Downloaded item is unsigned, and thus a notice is logged that the item is unsigned and future default OS behavior may not permit this to run. Goal: identify software that is currently not signed, to encourage future workflow developments whereby the result is signed code. 

I see case 2 as more serious than case 1 for long term health, and case 1 more serious for short term health. 

Regards,

Tom

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/BN6PR15MB1860DDF1BB178D6829AC66F2A3EB0%40BN6PR15MB1860.namprd15.prod.outlook.com.

For more options, visit https://groups.google.com/d/optout.

--

Tom Bridge

Brookland, DC

[Gregory Neagle]

But again: software installed via mechanisms like Munki or Jamf results in no quarantine flag, and in that case, Gatekeeper does not get involved and signing and notarization don't come into play.

It sounds to me like you want to use autopkg as a third-party software auditing mechanism...

-Greg

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/CAGQwz82-AEj7dBSaL7k2orQ_uUJKvgDktnyQouvSxqrb0iZsfg%40mail.gmail.com.

[Tom Bridge]

What I want is to plan for the future, and have autopkg help me do that.

I'm skating to what I'm seeing, which is a future where quarantine might be expanded to include binaries downloaded via curl, or where unsigned code is unavailable for install by default. The latter is writing in Apple's hand, the former is a possibility. 

Erring on the side of more information for admins to parse is a good goal, and worthy of pursuit.

-Greg

To unsubscribe from this group and stop receiving emails from it, send an email to autopkg...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/4FC31F58-06A8-41F8-BD5B-A3AF2D994A4A%40mac.com.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to autopkg...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/autopkg-discuss/BN6PR15MB1860DDF1BB178D6829AC66F2A3EB0%40BN6PR15MB1860.namprd15.prod.outlook.com.
For more options, visit https://groups.google.com/d/optout.

--

Tom Bridge

Brookland, DC

--
You received this message because you are subscribed to the Google Groups "autopkg-discuss" group.

To unsubscribe from this group and stop receiving emails from it, send an email to autopkg...@googlegroups.com.

[Michal Moravec]

I see two cases:

1. Check if downloaded software is notarized. 
• Perhaps we could add stapler validate check to CodeSignatureVerifier processor?
2. Notarized stuff as part of some workflows (automated repackaging perhaps?) which generate packages for users not system like Munki .
• This would require new processor.

[Gregory Neagle]

On Jun 18, 2019, at 8:24 AM, Michal Moravec <micha...@gmail.com> wrote:

I see two cases:

1. Check if downloaded software is notarized. 
• Perhaps we could add stapler validate check to CodeSignatureVerifier processor?

OK, but what if it isn't? You might want the recipe to fail in that case. But maybe I don't care if the software is notarized.

2. Notarized stuff as part of some workflows (automated repackaging perhaps?) which generate packages for users not system like Munki .
• This would require new processor.

That's an understandable use-case, but not the primary use-case autopkg was designed for and for which the current core developers are interested in at present.

I'm always concerned about new features that have the potential to greatly increase the support burden, and want to adopt them with care.

-Greg

[Michal Moravec]

On Tuesday, June 18, 2019 at 5:30:50 PM UTC+2, Gregory Neagle wrote:

On Jun 18, 2019, at 8:24 AM, Michal Moravec <micha...@gmail.com> wrote:

I see two cases:

1. Check if downloaded software is notarized. 
• Perhaps we could add stapler validate check to CodeSignatureVerifier processor?

OK, but what if it isn't? You might want the recipe to fail in that case. But maybe I don't care if the software is notarized.

This could an option for recipe author to decide.

We check the code signature to prevent the MitM attacks presenting invalid applications.

If we know software developer always notarizes and staples the software we can check for that staple and abort if it isn't there.

This way we know Apple "checked" the application and it was built with hardened runtime.

[James Stracey]

An old thread but @tom bridge, have you incorporate notarisation into your pipelines yet?

[Tom Bridge]

@James - nope, but that's mostly because I never actually had a problem with the recipes that we were using not having figured this out, and that Munki is a very effective solution that does not need to care about this in quite the same way.