"Read Anypath" Policy doesn't work as expected
Good day dev team!
Under Strict mode, I set up rules like:
watch prefix "~/" "any" w
watch prefix "~/Desktop/" "any" r
allow path "any" "/System/Library/CoreServices/Finder.app/" r "" "APPLE_PF_BINARY"
What is expected:
When I open files under ~/Desktop, DeepGuard should not make any dialog like "Finder is trying to read following files blablabla"
What really happened:
When I double click any files under ~/Desktop, DG indicates Finder is trying read files as pic bellow:
Thanks in advance & have a nice day!
Accepted Answer
-
Hi, @66f2e490!
Thanks for letting me know that you managed to find a suitable solution.
Finally, I also managed to reproduce this behaviour on my end. And I think I see the root cause of this behaviour after enabling more aggressive logging in the decision making part of DeepGuard.
As far as I can see, there is a concept of path complexity comparison which affects the final decision.
In the original set of rules
watch prefix "~/" "any" w watch prefix "~/Desktop/" "any" r allow path "any" "/System/Library/CoreServices/Finder.app/" r "" "APPLE_PF_BINARY"
the second rule sets up the watch policy for
~/Desktop/
directory overrides the following allow policy.The
paranoid.rc
ruleset from fsdiag contains the following rule.allow prefix "~/" "/System/Library/CoreServices/Finder.app/" rwc "" "APPLE_PF_BINARY"
I have a reason to believe that this is the culprit of this behaviour.
~/Desktop/
path is more specific/complex compared to the one from the allow policy~/
. That is why DeepGuard is giving priority to the watch rule and prompting to make the decision instead of making "allow" activity.I've quickly tested that after removing this rule more generic allow rule, DeepGuard stopped prompting for situations when Finder is trying to access files on Desktop.
So I think your instinct to revert the watch rule to be more generic was a right thing to do 😀
Now the allow and watch policies have the same complexity which makes DeepGuard respect the "allow" decision.
Best regards, Arthur
F-Secure Technology, Mac Team
Answers
-
Hi again, @66f2e490!
That's a curious find. I have now tried to reproduce it with FS Protection on a Monterey machine but unfortunately could not replicate this behaviour.
I currently have the three policies you have mentioned above and a bunch of other unrelated policies generated after running with DeepGuard Learning Mode on.
Would you mind submitting an fsdiag via beta.f-secure.com so that we could take a closer look at the issue that is happening on your machine?
Ideally let's do it like this
- Option click on the FS Protection icon in the menubar area and select "Enable debug logging" to install a configuration profile which will configure the logging subsystem of macOS to store debug logs to disk. It will most likely ask you to navigate to System Preferences app to approve installation of the profile.
- Reproduce the issue by triggering that dialog from DeepGuard
- Run Support Tool, collect fsdiag and attach it to a case on beta.f-secure.com
This way we'll receive the most accurate picture of why DeepGuard is making the decision to show that dialog.
Thanks in advance!
Best regards, Arthur
F-Secure Technology, Mac Team
-
Hi, @66f2e490!
A small update. Got finally a chance to look through your fsdiag. I can definitely see the log from DeepGuard engine that makes UI show the access prompt when Finder is attempting to read a file on Desktop.
According to the log, no policies that were in use by DeepGuard at that point matched against the incoming query. That's the reason the engine evaluated the query as of "ask" type. This evaluation result is then forwarded to the user.
I wanted to clarify one moment that is not entirely clear from fsdiag. Are you using the DeepGuard Configuration app to add those two watch and one allow policies? The reason I'm asking this is because for some reason, the "local.xfence.rc" file captured in fsdiag does not contain these policies you mentioned above which is a bit confusing to me at the moment.
The way I've tried to reproduce this so far is by switching to the Strict ruleset and adding the three policies above through the Configuration app UI. And after that, I can see them added to the file at "/Users/Shared/F-Secure XFENCE/local.xfence.rc" which is used to store custom user policies.
Thanks.
Best regards, Arthur
F-Secure Technology, Mac Team
-
Hi @ArthurVal ,
Thanks for the detailed answear.
These three policies are added to file "/Library/Application\ Support/XFENCE/paranoid.rc", I manually changed the default DeepGuard configuration files, that's why local.xfence.rc file seems not containing the related policies.
Btw, I just tried adding these three policies through the DG Conf-UI, but DG will still stop the Finder and ask for the approve.
Best regards!
-
@66f2e490, alright. Thanks for the clarification.
Yes, now I see how your flow looks like. One thing that I am curious about is whether you reload all the policies after you modify the paranoid.rc ruleset.
The primary flow of adding policies to DeepGuard is through the Configuration app for one main reason. The policies that are manually added to disk will not be taken into use automatically. The DeepGuard service needs to receive a signal from the Configuration app to apply new policies.
The Configuration app has functionality of applying policies when
- you click the lock icon in the lower left area of the window (locking after you are done with adding new policies)
- The new policies will be also applied once the Configuration app is closed
- And one more option is to press Command + R while the Configuration app is open to trigger a manual refresh of policies. Once you get the confirmation dialog about new policies getting applied, you should be ready to go.
Could you please try and let me know if DeepGuard starts letting Finder access files on the Desktop?
Thanks.
Best regards, Arthur
F-Secure Technology, Mac Team
-
Hi @ArthurVal
After reloading rules DG will still stop Finder accessing files in ~/Desktop.
Now I think watching special folders under "~/" may not be a good idea, this increases the complexity of the rules maintaining works. So I change the rules back to
watch prefix "~/" "any" rw
And everything works well now.
Thanks again for your help, sorry for the time occupied.
Best regards & Good day!
-
Hi @ArthurVal ,
Thanks for your reply
allow path "any" "/System/Library/CoreServices/Finder.app/" r "" "APPLE_PF_BINARY" allow prefix "~/" "/System/Library/CoreServices/Finder.app/" rwc "" "APPLE_PF_BINARY"
both these policies contain allow decisions for Finder's filesystem read actions. Since "~/" has a longer path than "any", so DG will take this line as the reference to make a decision. This makes DG keep asking me if I would allow Finder for accessing "~/Desktop".
Many thanks again and have a nice day!
🚩 What Do You Think?
We’d love your thoughts on our fresh look! Quick survey, big impact!