Notarized mode not blocking as expected

[codeskipper]

I've tried out BlockBlock Notarization Mode with app called Protégé, and with the command line executable for Neovim.

Expected behavior: for BlockBlock to block the launch, hoped for both the app and command line executable to be blocked.

Actual behavior: both app and command line executable launch unimpeded by BlockBlock. No messages show up in BlockBlock Helper app.

Testing with spctl shows both test objects are not notarized:

block@BlockTests-Virtual-Machine ~ % spctl -a -t exec -vvv /Users/block/Desktop/VirtualBuddyShared/VirtualBuddySharedFolder/Protege-5.6.5\ -\ un-quarantined/Protégé.app
/Users/block/Desktop/VirtualBuddyShared/VirtualBuddySharedFolder/Protege-5.6.5 - un-quarantined/Protégé.app: rejected
source=no usable signature

block@BlockTests-Virtual-Machine ~ % spctl -a -t exec -vvv /Users/block/Desktop/VirtualBuddyShared/VirtualBuddySharedFolder/nvim-macos-arm64/bin/nvim
/Users/block/Desktop/VirtualBuddyShared/VirtualBuddySharedFolder/nvim-macos-arm64/bin/nvim: rejected

codesign -dv shows both test objects are signed as flags=0x20002(adhoc,linker-signed).

Protegé is a Java app with Mach-O universal binary with 2 architectures: [x86_64:Mach-O 64-bit executable x86_64] [arm64:Mach-O 64-bit executable arm64] and nvmim is a Mach-O thin (arm64).

Tested on macOS version 26.01 Tahoe, and on a fresh install of 26.0 VM with no other 3rd party software in VirtualBuddy. On arm64.

[objective-see]

Currently (by design) BlockBlock only blocks user-downloaded files that have the quarantine attribute (com.apple.quarantine) set.

(You can check with xattr -p <path to file). So, if those files aren't quarantined BB will allow them ...

[codeskipper]

Ah thanks, that is not what I was expecting as Gatekeeper is already doing that task to a large extent when set to App Store and known developers.

I was looking to monitor/report for non-notarised and later maybe block if desired if our users download executables without the quarantine attribute set using (command line) tools or if they remove the quarantine attribute. (edited to correct spelling and terminology)

[agnosticlines]

Currently (by design) BlockBlock only blocks user-downloaded files that have the quarantine attribute (com.apple.quarantine) set.

It would be cool if this behaviour could be changed with an option, default it'd just block quarantine attribute files and if you enable this option it'll block everything and require approval for all unsigned/notarised code? You'd still have a database of approvals/rules stored so once you set it up with all your software you probably wouldn't run into it too much.

[agnosticlines]

@objective-see Hey! Congrats on the new release, I turned on the new mode but it's very hard to use because it's listing a bunch of software as unnotarized (my browser updater, etc) despite WhatsYourSign saying it's validly signed and notorized, I also can't make a new rule to allow it by default because I can't uncheck the temporary button

[objective-see]

@agnosticlines thanks for the bug report, if could provide any additional info via the following that'd be super helpful:

1. log stream --level debug --predicate="subsystem='com.objective-see.blockblock'"
   Run via terminal and then (re)launch any of the programs that are notarized but BB thinks are not. Share and relevant output here.

2. Share the links to the software or share the binaries that's it's flagging as non-notarized so I can run/test locally.

Mahalo!

[agnosticlines]

Hi @objective-see! This is from two runs opening a browser, it says it's not notarized but WhatsMySign says it is: https://gist.github.com/agnosticlines/8da8d9680afd60595d7753f59dbba80c (this only happens with All programs enabled)

[objective-see]

New version just released to fix this! Please lmk though if you're still encountering issues, and thanks again for the bug report! 🙏🏽

https://github.com/objective-see/BlockBlock/releases/tag/v2.4.1

[agnosticlines]

New version just released to fix this! Please lmk though if you're still encountering issues, and thanks again for the bug report! 🙏🏽

https://github.com/objective-see/BlockBlock/releases/tag/v2.4.1

I tried this and it appears the feature does nothing? I opened neovim and successfully get the prompt but if I just wait for a while it starts anyways, spawning subprocesses which cause another alert. I'm not super familiar with the BlockBlock code base, I only really started properly reading it today (I saw the change log mentioned clickfix which I was also looking into), if I was a little more familiar I'd try to locate the bug myself but figured it's best to mention here. I suspect it's to do with the process pausing/signal handling though given it seems to hang for 10-15s before just continuing execution anyways.

Also I've been reading the ClickFix code today and I see some gaps and bugs, I've been playing about with some fixes locally, but I think fundamentally addGlobalMonitorForEventsMatchingMask is a flawed approach because it receives copies of events, the docs even say "The event handler block object. It is passed the event to monitor. You are unable to change the event, merely observe it." so we're relying on the SIGSTOP being delivered before the paste is picked up by the terminal, which seems very racy to me.

There is however another approach (I was messaging you about this :D) that uses CGEventTap (with .defaultTap) which can swallow and hold the event and I've got a local demo working doing just that.

You're also missing quite a few local shells but I think relying on regex blocklists is a losing game which I think you agree with given the heuristics are off by default, I can PR a fix that increases the coverage if you want, it's your project I don't want to impose.

I've only been looking into this for a little while (thinking about it off and on for a few months, doing little bits of research here and there) and I could be totally wrong but I just wanted to share some thoughts from my research around this problem, I think there is a good solution here though that can meaningfully protect users from ClickFix attacks on mac and I'm a little annoyed Apple haven't done more here (they're mostly focusing on detecting the payloads that drop with XProtect behavioural signatures).

Actually seems we've been working on two similar problems at the same time which I'll take as a sign of confidence in my approach to these problems :D

I wish I'd updated this thread more, because once you said that this was by design (and there was no reply to my original post) I started building something that had that security property, as I recognised maybe you weren't interested in that specific area (too much friction for the average user maybe).

[objective-see]

1. The first issue, is really a (current) design decision. When BB gets an exec event, it's allowed to "pause" the process launch to alert the user, but only up to an Endpoint Security controlled deadline (~10 seconds). If it exceeds the deadline, macOS will forcibly kill BB!

if(0 != dispatch_semaphore_wait(deadlineSema, dispatch_time(DISPATCH_TIME_NOW, waitTime)))
{
                //err msg
                os_log_error(logHandle, "ERROR: ES timeout (%llu seconds) about to be hit, forced to allow process", waitTime / NSEC_PER_SEC);
                
                //sync
                @synchronized(self)
                {
                    //allow
                    if(YES != [self allowProcessEvent:client message:(es_message_t*)message cache:NO])
                    {
                        //err msg
                        os_log_error(logHandle, "ERROR: failed to allow process");
                    }

If the user does not respond by the deadline BB defaults to allowing the process. It could also not allow the process to launch, but that could break a bunch of stuff. Maybe it could have a option/setting that allows the user to decide what action should be taken when a ES deadline is about to be hit, as again, BB has to do something ...although will be killed!

2. You are correct that the ClickFix protection isn't perfect (as addGlobalMonitorForEventsMatchingMask is (slightly) reactive). The issue with CGEventTap is that:

"If your UX is “user hits Cmd+V → you pop an alert → user clicks Allow”, then you already swallowed the keystroke. To “deliver” the paste after the fact, you’d need to synthetically re-post Cmd+V (or trigger paste via some other mechanism, but there isn’t a clean universal “paste into whatever is focused” API)."

IMHO the only real solution is to wait for an Endpoint Security Paste Event from Apple 🤞🏽

[agnosticlines]

Thanks for the detailed response! I think we're mostly in agreement about the end goal, I would also love to see an ES paste event. On the reissuing specifically I think it's less of a problem than it seems? We have the pid of the terminal don't we? So we can repost an event to a specific PID using CGEvent.postToPid which solves the problem of 'no paste whatever is focused API' because we're posting to the thing that should have received the event?

I've put together a small demo from my local code that works blocking all pastes to a terminal except when allow is pressed where it resynthesises the paste event directly to the tracked terminal pid: https://gist.github.com/agnosticlines/7c2174acd9c25bb2b8c5fa67585bfad0

Additionally the reason I brought this up is because when my system was under load (both my original attempt and your code here) the SIGSTOP was being delivered too slow and the paste had already happened, I can reproduce this by adding a small delay in the code which breaks it consistently.

As for the notarisation requirement feature, I built something that fails closed (which I assumed BlockBlock was doing) which I think is the right approach instead of failing open, again you're the expert here I'm just trying to share some experiences from my research.

There's been times I've walked away from my computer and came back and a BlockBlock notarisation notification happened but by the time I'm back it's already been allowed to execute.

[agnosticlines]

It is almost certainly worth having at least an option to fail closed instead of fail open though, currently when people see these alerts if they take some time to google it or research it, it's likely the ESF deadline has expired and the application is currently running (or they don't see it because they're not in the room, in my case :P)

[objective-see]

https://github.com/objective-see/BlockBlock/releases/tag/v2.4.2

I've added a new preference/setting that allow you to control what happens on ES deadline timeout: