Skip to main content
Solved

Problems with ESET and Full Disk Access

  • May 4, 2022
  • 9 replies
  • 80 views
schoeM
Forum|alt.badge.img+3

Hello everyone,

I have a problem with my deployment of ESET via Jamf. I'm following their guide [KB8248] and I'm getting the software installed on the target machine, but the settings for Full Disk Access doesn't get pushed to the computer correctly. I can see the different components listed in the preference pane, but they are all unchecked, so ESET doesn't work.

During the installation the user gets asked for admin credentials ("macOS wants to make changes"), but no matter if I type them in or not the problem persists (nevertheless I'd rather get rid of that dialogue completely, because my users obviously don't run as admins).

Which additional information do you need to help me with this?

Best answer by Bol

When deploying TCC profiles via MDM, components listed in the preference pane remain unchecked although this is only a cosmetic bug ("feature") from all reports and testing. To troubleshoot and confirm your TCC profile has been correctly whitelisted ahead of time, run through your workflow from start and then check logs below;

/usr/bin/log show --predicate 'subsystem == "com.apple.TCC"' --info --last 1h

 Keep an eye out for these particular logs and note the extra info on bundle id's / binaries / location etc;

tccd: [com.apple.TCC:access] target_executable_path_URL:

tccd: [com.apple.TCC:access] AttributionChain:

 Then finally you will see if the profile meets the code requirement or not;

tccd: [com.apple.TCC:access] Override: eval: matched result: Auth:Unknown (<Unspported Authorization Reason value>); because: code does not meet requirement
or
tccd: [com.apple.TCC:access] Override: eval: matched result: Auth:Allowed (<Unspported Authorization Reason value>); because: code meets requirement

 Let us know how it goes!

    9 replies

    A
    • Anonymous
    • May 4, 2022

    we face the same issue. We push a configuration profile for ESET to our clients with full disk access for ESET. ESET is listed under "full disk access", but the preferences are unchecked. Until now, I could not find a solution for this.

      schoeM
      Forum|alt.badge.img+3
      • schoeM
      • Author
      • New Contributor
      • May 4, 2022

      we face the same issue. We push a configuration profile for ESET to our clients with full disk access for ESET. ESET is listed under "full disk access", but the preferences are unchecked. Until now, I could not find a solution for this.


      Does this apply to other software as well? ESET is the only thing I tried to deploy so far, as I am still in the eval-phase.

      A
      • Anonymous
      • May 4, 2022

      Does this apply to other software as well? ESET is the only thing I tried to deploy so far, as I am still in the eval-phase.


      I have to test this further. We deploy a bunch of apps. The most of them don't need a full disk access. At this time, we are testing some other things, because of this, it should be possible, to test this, too :) I will report here, when I got more informations.

      By the way: our employees were not be asked, if they want to grant full disk access. Right now, I cannot tell any issues with ESET, although the checkboxes are inactive. 

      Bol
      Forum|alt.badge.img+11
      • Bol
      • Contributor
      • Answer
      • May 4, 2022

      When deploying TCC profiles via MDM, components listed in the preference pane remain unchecked although this is only a cosmetic bug ("feature") from all reports and testing. To troubleshoot and confirm your TCC profile has been correctly whitelisted ahead of time, run through your workflow from start and then check logs below;

      /usr/bin/log show --predicate 'subsystem == "com.apple.TCC"' --info --last 1h

       Keep an eye out for these particular logs and note the extra info on bundle id's / binaries / location etc;

      tccd: [com.apple.TCC:access] target_executable_path_URL:

      tccd: [com.apple.TCC:access] AttributionChain:

       Then finally you will see if the profile meets the code requirement or not;

      tccd: [com.apple.TCC:access] Override: eval: matched result: Auth:Unknown (<Unspported Authorization Reason value>); because: code does not meet requirement
      or
      tccd: [com.apple.TCC:access] Override: eval: matched result: Auth:Allowed (<Unspported Authorization Reason value>); because: code meets requirement

       Let us know how it goes!

        schoeM
        Forum|alt.badge.img+3
        • schoeM
        • Author
        • New Contributor
        • May 5, 2022

        When deploying TCC profiles via MDM, components listed in the preference pane remain unchecked although this is only a cosmetic bug ("feature") from all reports and testing. To troubleshoot and confirm your TCC profile has been correctly whitelisted ahead of time, run through your workflow from start and then check logs below;

        /usr/bin/log show --predicate 'subsystem == "com.apple.TCC"' --info --last 1h

         Keep an eye out for these particular logs and note the extra info on bundle id's / binaries / location etc;

        tccd: [com.apple.TCC:access] target_executable_path_URL:

        tccd: [com.apple.TCC:access] AttributionChain:

         Then finally you will see if the profile meets the code requirement or not;

        tccd: [com.apple.TCC:access] Override: eval: matched result: Auth:Unknown (<Unspported Authorization Reason value>); because: code does not meet requirement
        or
        tccd: [com.apple.TCC:access] Override: eval: matched result: Auth:Allowed (<Unspported Authorization Reason value>); because: code meets requirement

         Let us know how it goes!


        I'm not sure if I am searching for the correct string. My logs do not show anything with Auth:Unknown in them, everything is on Auth:Allowed. Although I think I have found my error, which was a typo in the identifier.

        I still get prompted for admin credentials, because "macOS wants to make changes", but if I dismiss that dialogue four times I can't see any problems with my ESET installation, so I guess *this is fine* – or do you have any idea on how I could try to debug this?

        Is there already a Feedback# somewhere that I could hop on? I think it is a bit confusing, that the boxes aren't checked, even tough the profiles get properly installed.

        Bol
        Forum|alt.badge.img+11
        • Bol
        • Contributor
        • May 5, 2022

        Nice catch with the identifier typo, if that was the case there likely would of been 'does not meet code requirement' and showing the identifier presented in profile.

        Agreed, if it works it works but could you screenshot the dialogue box that is shown to the user. If it's a TCC security it will usually show the name of the binary is trying to access xx.

        You can also try either of the following to target specific TCC logs; eg. Anything Denied / Anything prompting the user..

        /usr/bin/log show -style syslog --predicate 'subsystem == "com.apple.TCC"' --info --last 1h | grep Prompting

        /usr/bin/log show -style syslog --predicate 'subsystem == "com.apple.TCC"' --info --last 1h | grep Deny

         Wonderful reading right here;

        https://krypted.com/mac-os-x/reviewing-tcc-dialog-prompts-using-logs-on-a-mac/

         

        schoeM
        Forum|alt.badge.img+3
        • schoeM
        • Author
        • New Contributor
        • May 5, 2022

        Nice catch with the identifier typo, if that was the case there likely would of been 'does not meet code requirement' and showing the identifier presented in profile.

        Agreed, if it works it works but could you screenshot the dialogue box that is shown to the user. If it's a TCC security it will usually show the name of the binary is trying to access xx.

        You can also try either of the following to target specific TCC logs; eg. Anything Denied / Anything prompting the user..

        /usr/bin/log show -style syslog --predicate 'subsystem == "com.apple.TCC"' --info --last 1h | grep Prompting

        /usr/bin/log show -style syslog --predicate 'subsystem == "com.apple.TCC"' --info --last 1h | grep Deny

         Wonderful reading right here;

        https://krypted.com/mac-os-x/reviewing-tcc-dialog-prompts-using-logs-on-a-mac/

         


        That's the screenshot of the dialogue box. I don't see any hints on what triggers the box. 

         

        The syslog corresponding to the timestamp of the screenshot shows something like this:

        2022-05-05 14:35:58.535700+0200 localhost tccd[143]: [com.apple.TCC:access] -[TCCDPlatformMacOS evaluatePolicyForPromptingforService:byIdentity:attributionChain:]: policyResult = 3; isApplePlatformBinary = 1

        There are multiple similar entries (~35), which only differ in the tccd#, which is sometimes 143 and sometimes 392.

        For the Deny it looks similar:

        2022-05-05 14:36:04.451595+0200 localhost tccd[392]: [com.apple.TCC:access] Platform binary prompting is 'Deny' because: is Platform Binary

        Bol
        Forum|alt.badge.img+11
        • Bol
        • Contributor
        • May 6, 2022

        Ok nice, that's not a TCC security prompt so we can rule that side out.

        Software installer looks to be making system changes that require admin auth. Im not familiar with deploying this but looking at their scripts, there's a dmg, pkg, tmp dir, etc. etc. all would be run as root via Jamf Policy.

        Sorry if you mentioned this but is this popup being triggered by someone manually installing part of this. I noticed there's a live installer extracted from a tar file which is documented, needs to be run as root and needing credentials.

        Deploy ESET Management Agent to a macOS client

        If it is you can add this into your Jamf workflow and it will be run as root. If this is occurring without user intervention then off to the logs to find out whats being touched.

         

        schoeM
        Forum|alt.badge.img+3
        • schoeM
        • Author
        • New Contributor
        • May 6, 2022

        Ok nice, that's not a TCC security prompt so we can rule that side out.

        Software installer looks to be making system changes that require admin auth. Im not familiar with deploying this but looking at their scripts, there's a dmg, pkg, tmp dir, etc. etc. all would be run as root via Jamf Policy.

        Sorry if you mentioned this but is this popup being triggered by someone manually installing part of this. I noticed there's a live installer extracted from a tar file which is documented, needs to be run as root and needing credentials.

        Deploy ESET Management Agent to a macOS client

        If it is you can add this into your Jamf workflow and it will be run as root. If this is occurring without user intervention then off to the logs to find out whats being touched.

         


        No, it's completely done via Jamf, no manual interaction. That's why I'm wondering, it already should run as root.

        Terms & ConditionsCookie settingsAccessibility statement