Just after peoples view on adding the `java.exe` process as a Trusted Updater within the Application Control rules. Naturally I have concerns about assigning this process the attribute as I feel it may reduce the effectiveness of Application Control by allowing unauthorised code (Java Classes) making changes to the system. We've come up against an issue where this maybe the only workable solution so I'm wanting to get a feel for the consensus of others.
yes – I also have very strong concerns about adding java.exe as an trusted updater.
I guess you may had such an issue with some (custom) java application that creates some executable files at runtime that are going to be run etc.?
Yes – that’s really bad. I think (but do not know) that maybe together with Change Control it would be possible to have a more granular configuration.
If you still have to define java as an updater, than I really would to it locally only / in a special policy that is assigned to systems only, that really need that rule.
Or maybe in this case (though usually not recommended) it would be better to have a special service account that runs this application (e.g. as a service, if possible) – and assign the update rights to this user, instead of java.exe.
We were actually able to work around our issue using the skiplist feature via the CLI on the local machine (refer to the MAC Program Guide for more information). Again skiplist has its own inherent risks, but certainly not of the concern that we had for allowing java.exe binary as an Updater. We've found skiplist very useful and I was excited to see that under MAC 7.0 release that functionality to manage skiplist via the ePO has been added. It's a shame that MAC 7.0 no longer supports legacy platforms.