While 1Password helpers are running: unable to "Allow" blocked extensions in System Preferences

parabellum

This is a weird problem, but I have reproduced on three different Macs.

While installing software that loads new system extensions to MacOS (for example, Intel Power Gadget, or Blackmagic Desktop Video), you are presented with a dialog saying "System Extension Blocked. If you want to enable these extensions , go to the Security and Privacy System preferences pane."

This is normal. No problem at this point.

However when you go to the pref pane and click "Allow" - nothing happens (if 1Password is running).

After force quitting all the 1Password processes, the "Allow" button works immediately.

This is apparently a security failsafe mechanism build into MacOS. If it detects software that could be taking control of the system, it prevents new system extensions from being "Allowed" to load.

I have reproduced this problem on two Macbook Pros, and an iMac; one of those was a recent clean install.

Anyone else seen this?

---

1Password Version: 1Password 7 Version 7.0.7 (70007001) Mac App Store
Extension Version: Not Provided
OS Version: 10.13.6
Sync Type: 1Password.com

parabellum

Dug a little deeper and found that 2BUA8C4S2C.com.agilebits.onepassword7-helper is the culprit, and even worse, it uses com.apple.security.temporary-exception.sbpl

So much for the sandbox.

Disregard the question above. I can figure out what's going on, and the workaround is to quit 1Password completely before doing anything that needs secure input.

I was already disappointed in Apple (no way for users to control / audit security entitlements), now I have a new rainy day project!

rudy

@parabellum,

com.apple.security.temporary-exception.sbpl will be gone in 7.2.

I'm not sure why secure input should be impacted by that entitlement though, or why secure input would be specified for anything other than a text input field.

parabellum

@rudy, I'm not sure either.

My discovery process went something like:
1. Noticed the issue with not being able to Allow new system extensions
2. Found several pages that described a similar problem (e.g. this page at Sophos)
3. Wondered what utility could be intercepting the trackpad/keyboard. Fortunately the first time this happened I was setting up a new machine and only had 1Password and nothing else. It's always the first thing I install.

I can't find any documentation on this behaviour from Apple (as usual) - it might exist, but I haven't found it yet.

Then I started to wonder why 1Password would cause this. Why would it need to intercept input events?

Then I realised that 1Password is an App Store app, and should be sandboxed.

Then I discovered the sandbox exceptions. At this point I realised I would need to spend a lot more time to get to the bottom of the behaviour (both 1Password, and MacOS) - but no time to spare. I like a good mystery though, so it will keep. I have not developed on Mac for many, many years - so the knowledge is a little rusty.

Open questions:

• Does 1Password intercept the input event stream? (something like Quartz event taps, perhaps?)
• If so, why?

rudy

@parabellum,

Nope, no intercepting of event streams at all.

the sbpl entitlement is strictly for allowing the application to be able to run the lsof command so that it can map an open TCP IP port to a specific process. This is how the legacy extension interface worked, and as I said will disappear as both TCP/IP based and the entitlement goes with it.

<key>com.apple.security.temporary-exception.sbpl</key> <array> <string>(if (defined? 'process-info-listpids) (allow process-info-listpids process-info-pidfdinfo))</string> </array> </key>

SecureTextInput is engaged only while in editing mode or on the master password screen, and only engaged by the main application, not he helper.

parabellum

@rudy, maybe worth opening a ticket with Apple on this behaviour then (assuming it is undesired and unintentional). It seems that 1Password is tripping whatever check Apple is doing to make sure the keyboard and mouse are secure. At least on the pref pane for allowing new kernel extensions.

Presumably this is GateKeeper / System Policy at work - or some other protection around adding new items to KextPolicy. Documentation in this area is thin and sketchy.

rudy

@parabellum,

I was able to install several kexts and click the approve button with both the current release version and the in-development versions of 1Password running here.

parabellum

@rudy

Thanks for taking the time to look at this; it is most strange. I just now tried resetting the kext policy (reboot to recovery mode and clear the policy database) on the machine I last experienced this with yesterday, and it worked fine; I was prompted to allow the extension, and that worked while 1Password was running.

It's strange because I observed this not once, but three times recently on different machines. The first time I was stumped and spent quite some time (and several reboots) trying to isolate the issue, finally quitting 1Password and having success. As I mentioned earlier, there was literally nothing else on the machine.

The second time I did nothing but kill 1Password and the Allow button immediately became functional.

I later installed different software on a third machine (yesterday) and let the problem unfold once again so that I could confirm my earlier observations. This isn't quite as strong a proof as I would generally demand, but 3 times in a row with the same result was enough to ask the question.

Now it's back in the deep mystery basket.

I've been running 1Password since 2009 and this is, I think, the first time I've had such a question. Certainly had not seen the issue until very recently.

AGAlumB

Very interesting. Thanks for the additional details! Perhaps we'll be able to learn something from it. I'm glad to hear that you were able to fix(?) it by resetting the policy, and that you've been enjoying 1Password (mostly) trouble-free for nearly a decade. Hopefully that continues for you, but we're here if you need us. :)