LuLu icon indicating copy to clipboard operation
LuLu copied to clipboard

Identify which rules are blocking a request

Open relikd opened this issue 5 months ago • 5 comments

Hi, I would like to ask for a tool to quickly identify which rules are blocking a request. I do block many Apple services and its hard to find which rule exactly is breaking a functionality. For example, currently I try to figure out which service is used for login to my Apple Dev account in Xcode (it is gsa, btw). And I dont want to disable LuLu completely. So I go trough likely rules and "allow" them, to see if it changes anything.

But I think this could be easily improved if we had a log view of recent block events. Then I could perform my service request and see what rules got triggered and hopefully find my culprit faster. (for privacy reasons, the log should not be active all the time. Either by limiting it to the last 1 min, or by only writing a log if the log window is open).

Thank you very much :)

relikd avatar Jul 20 '25 14:07 relikd

Aloha

From a terminal you can stream LuLu's log messages via:

log stream --level debug --predicate="subsystem='com.objective-see.lulu'"

This should show you the info you're after ...for example, here's the output of a block rule matching in curl

com.objective-see.lulu.extension: found matching rule for 17270/curl: RULE: pid: all, path: /usr/bin/curl, name: curl, code signing info: {
    signatureAuthorities =     (
        "Software Signing",
        "Apple Code Signing Certification Authority",
        "Apple Root CA"
    );
    signatureIdentifier = "com.apple.curl";
    signatureSigner = 1;
    signatureStatus = 0;
}, endpoint addr: *, endpoint port: *, action: 0, type: 3, creation: 2025-08-14 02:29:05 +0000, expiration: (null)

com.objective-see.lulu.extension: [com.objective-see.lulu:extension] setting verdict to: BLOCK

objective-see avatar Aug 14 '25 02:08 objective-see

uhh, nice. Thank you for the response, the log is sufficient for me. You can decide whether to close the issue or keep it open as a feature idea.

relikd avatar Aug 14 '25 03:08 relikd

Can we have tags for the log? There are a lot of "useless" logs (e.g. "checking bag.itunes.apple.com vs. weatherkit.apple.com") which spam the console. I am only interested if a rule matches and not all the checks before. And I dont think I can filter with what is given.

For example, I could filter for found matching rule for but that doesnt give me if the filter type (BLOCK or ALLOW). Filtering for rule says: will give me only the result but nothing else. And both of these would still miss the actual full URL only shown in the checking X vs. Y log message. Also I fear if I filter too much with my custom search strings, I may miss some logs in the future, e.g. if the log string format changes.

relikd avatar Aug 21 '25 13:08 relikd

Yes, I've added a new log message that shows: process path, flow endpoint, matching rule (if any), and verdict:

//log msg
// match on this if you want detailed insight into LuLu's decision
// log stream --level debug --predicate 'subsystem == "com.objective-see.lulu" && composedMessage BEGINSWITH "[LULU]"'

os_log_debug(logHandle, "[LULU] PROCESS: %{public}@, FLOW (endpoint): %{public}@, RULE: %{public}@, verdict: %{public}@", process.path, ((NEFilterSocketFlow*)flow).remoteEndpoint, matchingRule, verdict);

Image

Match with: log stream --level debug --predicate 'subsystem == "com.objective-see.lulu" && composedMessage BEGINSWITH "[LULU]"'

Is this sufficient for what you're looking for? :)

objective-see avatar Aug 26 '25 21:08 objective-see

Mostly, but I have a hard time understanding what information is shown and what not. I remember having seen a log message which showed the full URL of a request, but now I cant find any in my current logs. Will "FLOW (endpoint)" show the full request or just a host address like shown in the screenshot?

I have not put much effort into understanding all values, but what is the additional value for verdict (in contrast to just ALLOW or BLOCK)? Can I get more value out of this, or is this just some developer info? Same question for the rule, there are a few fields which are likely only relevant during development (e.g. creation date). Should these really be printed to the log?

It would be nice if the log line would start or end with information that can be used for filtering. I can understand the reason to start the line with the process name. In theory, that would make filtering easier. But the problem is, that I often dont know which process is run for a given task. For example the weather widget in Notification Center triggers at least three different services. (or the notorious WebKit Networking agent which can trigger from any application, uargh, I hate it).

What do I need to see?

  1. who is causing the request? (process, binary path, app or bundle name/path).
  2. where does it want to connect to? (domain, port, full url).
  3. which rule is responsible? (name of rule-group, actual rule pattern-string).
  4. was it / will it be blocked? (personally, I do not need more than ALLOW or BLOCK)

Also, now that I think of it, is it not a privacy concern if the full url is written to log? Can't other apps just tap in and read my "browsing history"?

And another idea: is it possible to configure log stream somehow to omit the header? If so, we could use a json log and pipe it through jq to extract whatever information anyone might want.

P.S.: any chance to fix the WebKit Networking behaviour and assign the request to the appropriate app? (I am afraid not)

P.P.S.: thank you and sorry for my whining ^^

relikd avatar Aug 26 '25 22:08 relikd