Jump to content

ESET 6.7.500.0 and 10.14 Mojave TCC issue)


brandobot

Recommended Posts

We allowed "All Files" in a configuration profile for our Macs on Mojave, but upon installing 6.7.500.0, we still get prompted to manually go to system preferences >> privacy and allow full disk permission. 

Upon further investigating, we found that the app itself does not have a unique identifier and is just using the "anchor apple generic". I don't think the app is properly code signed, which is causing the TCC exception not to go through. Obviously this is a huge blocker as we cannot reliable deploy ESET to our environment. (see screenshots for ESET code sign vs Discord code sign. All apps should have a unique identifier.)

 

Also, another huge annoying issue that has been around for years is the ESET splash screen and the console launches upon installing the .pkg. We do not want to pop up the splash screen and ESET gui during upgrades for all of our end users. Please give us an option to do a silent install.
 

image.png.b387a59da7f57d23bab0f4f0a0360af2.png

image.thumb.png.e5d00df8dae56cf5ab869cd0a847ed65.png

image.thumb.png.1967135ffb32ef10d58e34e3526292db.pngimage.png.b387a59da7f57d23bab0f4f0a0360af2.png

 

image.png

Link to comment
Share on other sites

Testing 6.7.500.0 last week we came across the same issue. It seemed like an easy fix, we had already allowed "All Files" in a configuration profile for our Macs on Mojave, so I made sure the new tcc profile was installing but again we are prompted to manually allow full disk permission. 

If it's using "anchor apple generic" that would make sense now. We have testing the install and upgrade on a few machines all with the same result, so it's holding up our move to production upgrades as well.

And I am so in if the splash screen can be made at least scriptable option in the install process. 

Link to comment
Share on other sites

Hi, 

I just spotted the same problem in our environment. Without automatically allowing full disk permission for Eset I can't deploy that new update to our users. That's a real pitty. 

Also +1 for the option of hiding Eset splash screen on update from .pkg.

Link to comment
Share on other sites

Adding this link about privacy policy controls -- https://derflounder.wordpress.com/2018/08/31/creating-privacy-preferences-policy-control-profiles-for-macos/

#1 on the list - "Item being whitelisted must be code-signed"... so that explains why it's not working as the ESET app is not properly code signed

Link to comment
Share on other sites

  • ESET Moderators

Dear @brandobot,

The code signature is valid, just run in terminal:

 

codesign --verify --verbose /Applications/ESET\ Endpoint\ Security.app

the output should be exactly like this:

/Applications/ESET Endpoint Security.app: valid on disk

/Applications/ESET Endpoint Security.app: satisfies its Designated Requirement

Also the identifier is set to value "com.eset.ees.6", to see run in terminal:

codesign --display --verbose /Applications/ESET\ Endpoint\ Security.app

Output:

dan43:Src adam$ codesign --display --verbose /Applications/ESET\ Endpoint\ Security.app

Executable=/Applications/ESET Endpoint Security.app/Contents/MacOS/esets_gui
Identifier=com.eset.ees.6
Format=app bundle with Mach-O thin (x86_64)
CodeDirectory v=20200 size=39342 flags=0x0(none) hashes=1224+3 location=embedded
Signature size=9054
Timestamp=23. 10. 2018, 21:28:45
Info.plist entries=29
TeamIdentifier=P8DQRXPVLP
Sealed Resources version=2 rules=13 files=424
Internal requirements count=1 size=36

So it is signed, clients aren't executing unsigned code.

Nevertheless, we are using only the "apple anchor generic" requirement which is pretty broad. This requirement is something that the application itself specifies for the system to know when it should consider its signature valid. It seems weird to me that TCC would look at the form of the requirement, but I guess its possible.

 

We are currently testing the possibilities how to add our product to the full disk access list in the macOS.

 

When it comes to the Silent installation, you need to create a flag file in advance in the following location: '/Library/Application Support/ESET/esets/cache/do_not_launch_esets_gui_after_installation'

To the GUI won't startl, then you should send them a policy to disable the splash screen and start the GUI manually.

Regards, P.R.

Link to comment
Share on other sites

17 hours ago, Peter Randziak said:

Dear @brandobot,

The code signature is valid, just run in terminal:

 


codesign --verify --verbose /Applications/ESET\ Endpoint\ Security.app

the output should be exactly like this:

/Applications/ESET Endpoint Security.app: valid on disk


/Applications/ESET Endpoint Security.app: satisfies its Designated Requirement

Also the identifier is set to value "com.eset.ees.6", to see run in terminal:

codesign --display --verbose /Applications/ESET\ Endpoint\ Security.app

Output:

dan43:Src adam$ codesign --display --verbose /Applications/ESET\ Endpoint\ Security.app


Executable=/Applications/ESET Endpoint Security.app/Contents/MacOS/esets_gui

Identifier=com.eset.ees.6

Format=app bundle with Mach-O thin (x86_64)

CodeDirectory v=20200 size=39342 flags=0x0(none) hashes=1224+3 location=embedded

Signature size=9054

Timestamp=23. 10. 2018, 21:28:45

Info.plist entries=29

TeamIdentifier=P8DQRXPVLP

Sealed Resources version=2 rules=13 files=424

Internal requirements count=1 size=36

So it is signed, clients aren't executing unsigned code.

Nevertheless, we are using only the "apple anchor generic" requirement which is pretty broad. This requirement is something that the application itself specifies for the system to know when it should consider its signature valid. It seems weird to me that TCC would look at the form of the requirement, but I guess its possible.

 

We are currently testing the possibilities how to add our product to the full disk access list in the macOS.

 

When it comes to the Silent installation, you need to create a flag file in advance in the following location: '/Library/Application Support/ESET/esets/cache/do_not_launch_esets_gui_after_installation'

To the GUI won't startl, then you should send them a policy to disable the splash screen and start the GUI manually.

Regards, P.R.

A majority of us are using Jamf’s PPPC utility to test. To test, create a configuration profile for eset endpoint security for full disk access, deploy via mdm, then install ESET Endpoint Security to see if the same pop up comes up. 

 

When we talk about TCC, this is a built-in mechanism by Apple in the Mojave operating system. 

 

Link to pppc utility: 

https://github.com/jamf/PPPC-Utility

 

Link to tcc database reset script. Run this before testing a new config profile to reset the previous applied tcc exclusions:

https://gist.github.com/haircut/aeb22c853b0ae4b483a76320ccc8c8e9#file-tcc-reset-py

 

Thanks for the suppressing gui option. Just to confirm, just create an empty file with the name above? 

Link to comment
Share on other sites

  • ESET Moderators

Thank you for the additional info on the ways how you manage and test, I have forwarded it internally.

2 hours ago, brandobot said:

Thanks for the suppressing gui option. Just to confirm, just create an empty file with the name above? 

Yes it should work that way.

Link to comment
Share on other sites

  • ESET Moderators

Hello,

We have made some changes to the way our code signing works and now it should satisfy the requirements mentioned in this thread.
Are you interested in testing a beta build with this change implemented?

Regards,
T.

Link to comment
Share on other sites

I'll test it.

 

Also, to verify codesign, try "codesign -dr - /Applications/ESET\ Endpoint\ Security.app/Contents/MacOS/esets_gui"

It is returning "anchor apple generic", which is invalid.

Link to comment
Share on other sites

On 11/22/2018 at 10:53 PM, Peter Randziak said:

When it comes to the Silent installation, you need to create a flag file in advance in the following location: '/Library/Application Support/ESET/esets/cache/do_not_launch_esets_gui_after_installation'

To the GUI won't startl, then you should send them a policy to disable the splash screen and start the GUI manually.

How do you even do this sort of client configuration, though? I cannot find any documentation about configuring ESET Endpoint Antivirus that actually works. esets_set is ignored by the app, as it's using a different file in a different location (/Library/Application Support/etc/esets.cfg vs /Library/Application Support/ESET/esets/cache/data/settings.json). The configuration that is actively in use (settings.json) doesn't have a command line tool to modify it (without actually learning json).

Link to comment
Share on other sites

I just tested suppressing the GUI upon install by creating an empty file into the "cache" folder and it apperas to work. The esets_gui process does not launch, there is no splash screen, and no icon in the menu bar. I am able to verify that the proxy, mac, fcor, daemon, pidmapper and ctl processes are running in activity monitor. Does this mean the machine is still being fully protected?

Not a huge issue, but Is there a way to suppress the splash screen upon install, but retain the ESET icon in the menu bar?

Another thing I noticed is that the "do_not_launch_esets_gui_after_installation" file is removed after the install. So after every upgrade, we'll have to re-create the file.

Edited by brandobot
Link to comment
Share on other sites

Same issue with the beta version. I've created a new config profile based on the beta to allow both all app data and system files. 
I tested by uninstalling ESET, applying the configuration profile, restarting the Mac, then re-installing the Beta version. 

 

 

 

 

image.png

Edited by brandobot
Link to comment
Share on other sites

  • ESET Moderators

Hello,

As for the silent installation - it is designed as a one-time feature. It allows to install the product without running the GUI. Then you can apply configuration that satisfies your criteria: disabling splash screen, tray icon, etc... After product upgrade, these settings would be preserved and applied to new version too.

Regarding the TCC policy, the development team would like to ask you to test it for a different process, in order to compare the results:

  1. Open iPhoto and add any picture in the library (if you did not use iPhoto yet. This is required to create photo library on disk that is protected by TCC).
  2. If Terminal has NOT granted Photo access yet, try to create a file by Terminal in iPhoto library, e.g.:
sudo touch ~/Pictures/Photos\ Library.photoslibrary/database/a.txt
  1. If Terminal has not granted Photos access, system will show panels where it asks you to decide whether to allow that access. It is important to do nothing, e.g. DO NOT grant Terminal access to Photos
  2. Create TCC profile for Terminal, grant it Full Disk Access
  3. Apply that TCC profile on iMac
  4. Repeat step 2.
  5. If the file was created, Terminal has granted access and the TCC profile is working.
  6. If the file WAS NOT created, the TCC policy process is not working and problem is outside of our product
Link to comment
Share on other sites

@TomasP

Hello,

I just finished running through the instructions for the TCC policy and tested on two machines.

  1. Created a photo library
  2. Attempted to create a file via terminal but access was prompted to grant terminal access. Did not grant terminal access
  3. Generated a TCC profile for terminal granting it full Disk Access
  4. Applied to the machines
  5. Attempted to create a file via terminal, no prompt to grant terminal access, file created.
Link to comment
Share on other sites

With some testing, does not seem to be a TCC Profile Issue. If you do a " sudo log stream -debug -predicate 'subsystem == "com.apple.TCC"' | grep 'eset'" when restarting the client on a machine with a SystemPolicyAllFiles Profile for com.eset.eea.6, you see "2018-11-30 12:30:26.438122-0500 0x477bb    Info        0x534e2              314    0    tccd: [com.apple.TCC:access] Override: found override in <TCCDMDMPolicyOverride: 0x7f8cbc4009a0> for kTCCServiceSystemPolicyAllFiles and com.eset.eea.6". I'm assuming that whatever methodology ESET is using to check for access is not taking into account MDMOverrides.plist. Funnily enough, version 6.866 worked fine with the a PPPC Payload deployed. Currently engaged with support over this.

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...