Lulu blocking on "allow" (or nonexistent) rules (e.g for SSH)

[CoffeePocket]

(I am using LuLu 0.9.5, I will try upgrading and see if that fixes it... when I wrote the following, I didn't know there was a new version as the "check for update" feature indicated "no new versions.")

Lulu will sometimes block a connection even though no rule exists.

For example, I noticed LuLu was blocking (some, not all) outgoing SSH connections.

(Whether this is because I was using a nonstandard SSH port is unknown.)

SSH had sometimes worked, and there was an "allow" rule in LuLu for SSH.

I therefore deleted the ssh rule in Lulu entirely. Searching the "all" tab of the LuLu rules window for "ssh" produces no results.

However, my next attempt to connect out via ssh was still blocked, and the system console log contained the message: "LULU: rule says block for ssh (pid: 31795)"

After disabling and re-enabling LuLu, SSH started working again.

I have also seen this behavior with other software, where it simply cannot connect out until I disable LuLu... even though there is no rule, or an "allow" rule for that software in LuLu.

And just in case this wasn't weird enough?

A few hours later the same behavior re-occurred, with LuLu all of a sudden blocking SSH outgoing again.

My suspicion as to what's going on: the LuLu kext may be blocking the connection before it can get the message (from the LuLu application and code signing checker) that the process is OK.

Here is the sequence of log entries that leads up to this, in chronological order:

LuLu(93): process start: /usr/bin/ssh (32242)
LuLu(93): determing code signing flags for /usr/bin/ssh/(null)
LuLu(93): generating code signing info for ssh (32242) with flags: 13
LULU: rule action for 32242: 0
LULU: processing outgoing network event for ssh (pid: 32242 / action: 0)
nw_socket_connect connectx failed (fd 4, x.x.x.x:yyyyy stream, pid: 32242): [1] Operation not permitted
LULU: rule says block for ssh (pid: 32242)
LuLu(93): done generating code signing info
LuLu(93): found matching rule: {
    action = 1;
    signingInfo =     {
        signatureStatus = 0;
        signedByApple = 1;
        signingAuthorities =         (
            "Software Signing",
            "Apple Code Signing Certification Authority",
            "Apple Root CA"
        );
        signingIdentifier = "com.apple.openssh";
    };
    type = 3;
    user = XXX;
}
LuLu(93): sending msg to kext: 'add rule' (pid: 32242, action: 1)
LULU: in (IOUserClient) externalMethod
LULU: in sAddRule
LULU: added rule 32242/1

[objective-see]

Mahalo for the detailed bug report!

I believe this is a result of a bug where a "process end event", didn't trigger the removal of the pid -> rule mapping. Thus when a new process started that had the same pid as an old process (i.e. 32242) the kext would think it already had a rule for that pid

This might also explain why the bug appeared after a hours?

As of the LuLu 0.9.7 Release, the pid -> rule mappings are fully removed when a process ends.

I'll keep digging to see if there is another issue that could explain your bug. But in the meantime if you could install/test the latest release and see if it fixes the issue, that'd be incredibly helpful!

[CoffeePocket]

Hey, that could be, but I doubt it.

Maybe it wasn't clear from the logs, but I have no reason to believe the pid 32242 had ever been used before (on the current boot anyway).

[hpmike48]

Hello! Im a new B here and just wanted to know if i can use BlockBlock (beta)RansomWhereOverSight What's Your Sign ? or is that to mush for my Mac?