Option to disable new "code signature"-related forced alerts?

[zhimsel]

In Little Snitch 4.0.5, a new feature was introduced:

A Connection Alert informing about a code signature mismatch is now shown even if Silent Mode is active. This is to prevent processes with an invalid code signature from communicating even in Silent Mode.

This is a great idea, and I'm glad it was implemented, but I feel like there should be an option to turn it off. Personally, I use LS primarily to block network connections on untrusted networks until I can connect to a trusted VPN. As such, my "trusted" profile allows all connections silently.

This new feature forces upon me the connection alert dialogs that I don't want while on a trusted network. Especially considering all the alerts for code signature mismatches are from commandline utilities that I trust.

While I'm not privy to your codebase, I feel like having an option to disable that "alert even in silent mode" behavior should be pretty easy to implement.

Thanks!

[marco]

We found that the current implementation of this behavior is a bit more aggressive than originally intended. This will be improved in an upcoming release. We haven’t discussed yet if there should be an option to turn this off entirely, but we will take your feedback into consideration.

For now, you can create allow rules for the command line tools you mentioned. Or, when you already have a “trusted” profile in which Silent Allow Mode is active, you could create an allow rule in this profile for “Terminal” that allows connections to any server, while ignoring any code signature.

Could it be that the Connection Alerts you see are for processes that just don’t have any code signature? This is common for command line tools installed via Homebrew, for example.

These Connection Alerts during Silent Mode are intended to only be shown for severe problems where something is definitely and provably wrong. IIRC, these situations are:

1. When a running process has an invalid code signature. This means that the executable was modified since the developer signed it, or the running process did something that invalidated its code signature (e.g. it loaded a third party library that has an invalid code signature).
2. When you have existing rules that require a specific code signature, but the running process has either no code signature or a different code signature. That can be the case when the executable was replaced with one from a different developer since you created the rules, for example.

FYI: The latter point is what we call a “code signature mismatch”: It’s a mismatch between the running process’ code signature and the code signature an existing rule requires.

[zhimsel]

We found that the current implementation of this behavior is a bit more aggressive than originally intended. This will be improved in an upcoming release. We haven’t discussed yet if there should be an option to turn this off entirely, but we will take your feedback into consideration.

That's great to hear! Personally, I'd recommend simply having a user-configurable "level" (which could just be "on" or "off") for this feature would be great. I can definitely see the usefulness of it in most situations, but not if it's forced. Having it "on" by default is definitely a good idea.

...when you already have a “trusted” profile in which Silent Allow Mode is active, you could create an allow rule in this profile... ignoring any code signature.

This is what I ended up doing. Figured out that you could manually add a global rule to allow all outgoing connections, ignoring code signatures. This works well enough, for now (for my situation at least).

Could it be that the Connection Alerts you see are for processes that just don’t have any code signature? This is common for command line tools installed via Homebrew, for example.

Sorry if my original post did not explain it well, but that's exactly what I meant. Valid-sig'd connections were being allowed silently (as expected), but only connections with invalid signatures were showing the alerts.

[marco]

Glad to hear the workaround works for now!

FYI: The reason why I asked about “no code signature” specifically is that the wording is quite important here. There’s a huge difference between “no code signature” and “invalid code signature”. The former means that the executable or process is simply not signed at all, while the latter means that it was signed, but was then modified in a way that broke the code signature.

[DblD]

So @marco, can you please elaborate or point me to resources on how is this code signature validation performed. I've got few applications installed with brew, and i've noticed this blocking notification but im not really sure how to verify said code signature invalidation.

[marco]

So @marco, can you please elaborate or point me to resources on how is this code signature validation performed. I've got few applications installed with brew, and i've noticed this blocking notification but im not really sure how to verify said code signature invalidation.

Little Snitch uses functionality provided by macOS to verify the code signature of running processes, as well as of executables on disk. Specifically, the C function SecStaticCodeCheckValidityWithErrors() from Apple’s Security.framework is used. You can find developer documentation on code signing for Apple platforms in Apple’s Code Signing Guide.

This is equivalent to using the codesign command in Terminal. You can find more information in that command’s man page by entering man codesign.

[wacalu]

What can I do to make this work again?

https://www.evernote.com/l/AAybQZulQnhF ... xutndgdXmE

https://www.evernote.com/l/AAw7NCjp8nhE ... gICxsmoVPM

Do I really need to turn off little snitch? Isn't there a way how to make an exception?
I cannot work like that.

[sjthespian]

Like others, I'm having no end of issues with the new code signature blocking, especially with applications installed via. brew. For example, I can't use "git clone" at the moment, because:

On Apr 20, 2018, iTerm via git-remote-https tried to establish a connection to github.wdig.com. The request was denied automatically during Silent Mode because of an invalid code signature.

Even though when I hit the checkmark icon it tells me that iTerm has a valid signature. It is almost as if it is comparing the signature of the command being run inside of iTerm to the iTerm signature.

Is there any hope of a fix/workaround for this issue other than disabling Little Snitch? I'm currently running 4.0.6 and don't see any way around the issue other than turning off network filtering. I can't even put in a rule to override it as the auto-generated rule is "Extra High" priority.

[marco]

wacalu and sjthespian, I just updated the troubleshooting section of the online help for Little Snitch 4 to (hopefully) be clearer what is going on in this case. This section tries to explain exactly what happens in the case documented by wacalu’s screenshots:
https://help.obdev.at/littlesnitch/#/ad ... viaprocess

In these screenshots I can see that there are rules for iTerm that allow any connection and that require a valid code signature. That means that any command that is run in iTerm must also have a valid code signature for the rule to work. But because git-lfs has no code signature, it violates what the rule requires. Little Snitch calls that a code signature mismatch.

There are two possible solutions:

1. Create a rule for iTerm via git-lfs that does not require a valid code signature.

2. Create a rule for only iTerm that does not require a valid code signature. This will automatically ignore the code signature of any command run inside iTerm.

After that, delete any of these code signature issue override rules that may still exist. I hope this helps!

Note: In the next version of Little Snitch, we’ll make these override rules editable so you can simply change them to allow connections. This should ease the pain of running into this issue, but we’re aware that this is not the ultimate solution to this whole problem.

[cortig]

FYI: The latter point is what we call a “code signature mismatch”: It’s a mismatch between the running process’ code signature and the code signature an existing rule requires.

Could there be an issue with this later aspect in LittleSnitch?
I've had two apps (Undercover 6.6 and Lingon X 6.0) that were denied connections based on an invalid code.
I checked everything I could think of using codesign in the Terminal and couldn't see anything wrong.
I deleted the pre-existing rules that used to allow the apps to connect and the newly automatically created ones denying them access and relaunched them. Little Snitch re-created new rules that were perfectly OK with the new code signature.

I suspect the developers might have made changes in their code signatures, though the apps had valid code signatures…

Corentin

[marco]

I've had two apps (Undercover 6.6 and Lingon X 6.0) that were denied connections based on an invalid code.

[…]

Little Snitch re-created new rules that were perfectly OK with the new code signature.

I suspect the developers might have made changes in their code signatures, though the apps had valid code signatures…

It’s hard to say what was going on without more details. Especially the kind of code signature mismatch that Little Snitch reported would be helpful to diagnose this.

If the developers of these apps changed certain properties that affect the code signature that Little Snitch expects to stay the same across app updates, it might be a problem. Namely, Little Snitch stores the code signature’s identifier (usually the app’s bundle identifier) and team identifier.

Changes in the identifier may happen in any update and Little Snitch will handle this silently (at least in Little Snitch 4.0.5 and later), while changes in the team identifier indicate that the app is from a different developer and that is something that cannot be handled automatically.

You can find more information about this in the help section Code Signature Issues > Applications that change their bundle identifier in an update.

[cortig]

I wish I had all the details of what the precise code signature issue was, but I no longer have the older version of the apps installed so it's not that easy to figure out what the exact difference is. I looked at the certificates at the time and didn't notice anything, but it's easy to miss the details, especially since I didn't know then what Lilttle Snitch payed attention to.
In any case, I contacted the developers of both apps to let them know and from what I understood they're looking into it.

Corentin

[marco]

If there’s anything I can do to help the developers of these apps, don’t hesitate to contact me or tell them to contact me directly (I can send you my email address via PM if necessary). I’m happy to help.

[cortig]

I'll let you know if I hear anything back from them Marco.

Corentin

[cortig]

I just saw it with another app: ColorMunki Display from X-Rite.
The situation might be a little different here. If I use codesign in the Terminal I get the following warning:

Code: Select all

$ codesign --verify --verbose=4 /Applications/ColorMunki\ Display/ColorMunki\ Display.app 
/Applications/ColorMunki Display/ColorMunki Display.app: resource envelope is obsolete (version 1 signature)

I didn't have any warning for the other two apps.
That being said, the certificate doesn't appear to have changed at all between this version and the previous one and if I compare the certificates in Little Snitch Configuration between the older rule and the new one denying connection I can't see any difference.



Corentin