DeepGuard keeps asking for mount events

66f2e490 · February 2023

Hi Dev team,

Good day, after upgrading to version 3.0.48998 (48998), DG keeps asking for mount events, the problem here is that I don't have any "watch" rule for mount events. Changing mode from "Strict" to "Default" or "Classic" does NOT help.

The version I used before this was 18.4, and I didn't encounter this problem.

Currently I'm using this rule to mute all mount events:

allow prefix "/" "any" m

System environment: macOS 13.2.1 (22D68)

Best regards.

ArthurVal · December 2023

Hello, @66f2e490!

Thanks for the fsdiag. Managed to confirm my theory by looking at debug level logs.

In the current state, DeepGuard is configured to monitor mount events regardless of presence of mount rules. The reason why it did not prompt before is due to the fact that mount support was kept disabled due to bugs on Apple's side.

Starting from build 48998, we have re-enabled mount event support for DeepGuard. It was kept disabled previously due to improper handling of mount events on Apple's Endpoint Security framework side. Once we got a confirmation from Apple that they improved handling and fixed a few breaking bugs, we re-enabled support when the product is running on macOS 11.4 and higher. Apple did not manage to / decided to fix the bugs that we reported on earlier macOS versions.

When DeepGuard is running in "Default" mode, it does not prompt the user about mount operations as it's configured to place more trust in the operating system actions to fit the profile of an average user of the product.

The "Strict" mode configures DeepGuard to be more strict and trust as little as possible. So it skips the additional allow rules that are active in "Default" mode and proceeds to prompt about mount operations.

So indeed the current solution to suppress mount prompts in "Strict" mode is to create a wide allow policy that will configure DeepGuard to allow such events without generating a prompt.

We will discuss with the team if it makes sense to keep the override for mount rules that does not respect the presence of mount rules. The reasoning for that escapes me to be honest.

I do expect a possibility that this is a leftover from the time when DeepGuard used to run in the kernel context as part a kernel extension (which is no longer the case). So perhaps we can unify the logic for mount events and the rest of policies to provide more clear expectations.

ArthurVal · March 2023

Hi, @66f2e490!

Could you please run Support Tool and submit fsdiag.tar.gz file on beta.f-secure.com?

We can then take a closer look to diagnose this behaviour. Thanks.

66f2e490 · July 2023

https://community.f-secure.com/en/discussion/comment/132200#Comment_132200

Hi Arthur,

Just upload, SAFE_BUG-04012.

best regards,

ArthurVal · July 2023

Thanks!

We will take a look and will get back to you as soon as we learn more about the root cause behind this behaviour.

ArthurVal · September 2023

Hi, @66f2e490!

Took a look at the diagnostics shared previously. Found some evidence of DeepGuard trying to show a prompt for a mount operation. But unfortunately, most of the decision making logs are debug level which are not stored/available for collection by our Support Tool by default.

In my own testing, I could reproduce the behavior in the Strict mode of DeepGuard as it sets a very low level of trust to system activity in general. But other rulesets did not cause prompts for mount activity.

One thing came to mind since you mentioned that this behavior started happening after a product update. For quite awhile we did have mount support on DeepGuard side disabled due to issues on Apple's side with how the system treats user "deny" actions. We have been in contact with Apple and they fixed few reported use case scenarios. Following that, we re-enabled support for mount operations on DeepGuard side. So that could explain why the behaviour was not observed previously as this type of operations was not intercepted by DeepGuard.

If the issue is still occurring on your Mac, I would suggest enabling debug level logs to reproduce the issue again and collect fsdiag capture once more. Hopefully that will reveal the situation in more detail.

One note worth mentioning. I've noticed an unexpected configuration of our product captured in fsdiag. There is only a limited number of crucial services running. This adds up entropy in the core functionality services like DeepGuard. This is something to keep in mind as we usually focus on the default configuration of the product during development & testing taking into account that some features like DeepGuard allow customization such as alternate rulesets.

The tune up that DeepGuard performs when ruleset is changed takes into account graceful disabling of unused services.

Those customization options which are offered by the product are of course covered in our testing. But for example disabling or removal of product helper processes which are made with help of external tools are generally advised against as we cannot guarantee certainty level of quality in this case.

66f2e490 · November 2023

https://community.f-secure.com/en/discussion/comment/134064#Comment_134064

Hi @ArthurVal,

Thanks! Would like to know how to "enabling debug level logs", as this issue still exists with F-Secure 19.3 and macOS Sonoma 14.1.1 (23B81).

ArthurVal · November 2023

https://community.f-secure.com/en/discussion/comment/134977#Comment_134977

Hi!

You should be able to enable debug logging mode in FS Protection settings.

Click on the FS Protection icon in the menubar area
Click "Settings..." -> "Support" -> "Enable debug logging"
Navigate to Privacy & Security section of macOS System Settings app
Scroll down to "Profiles" section
You should see a new profile. Double-click on it and follow on-screen instructions to complete the install procedure.
One the profile is installed, please reproduce the issue and run Support Tool to collect a new fsdiag archive with debug log messages.

Thanks!