Troja wrote:
Hmmm,
i tested with HF929019, no Access Protection any more.
Cheers
REGISTERED - VirusScan Enterprise 8.8 Patch 4 Hotfix 929019 Known Issues
Technical Articles ID: KB83215
Reference Number | Related Article | Issue Description |
1031673 | KB83808 | Access Protection rules are disabled (not being enforced) because of an invalid character in the rule policy |
Should you find you saw this behavior for a different reason, I suggest engaging Support.
We have no invalid characters , we tried with 1 file in the exclusions. Nothing exotic.
the same goes for the mass mailing rule in access protection . New exceptions are not accepted.
the rules aren't disabled in our case but are just no longer usable because they don't see the exceptions
Resellers are sending mailings to their customers stating not to use P5 , but on the the McAfee download website it is still there...
I'm not sure if it's exactly the same issue but this may be worth a read. McAfee KnowledgeBase - VirusScan Enterprise 8.8 could block McAfee processes after installing or upd...
Troja wrote:
hi wwarren,
OMG, i have not seen this. Thanks for the info! :-)
Lets try if Patch 5 resolves this...
Cheers
Yes, that particular issue I referred to has been confirmed solved with Patch 5.
But as we are seeing in other related conversations, there are yet other issues introduced or catalyzed by Patch 5 we still need to better understand (and we're working on it still).
I still see Patch 5 on the download site... Isn't it time to revoke this ? Or at least come up with a fix ?
paradroid wrote:
I still see Patch 5 on the download site... Isn't it time to revoke this ? Or at least come up with a fix ?
No, it's not.
This isn't the place if you were looking for any kind of official response to that first question. However, if you're open to a candid response to the candid question, then allow me...
The issue reported is of Access Protection exclusions not working, meaning we're talking about the "Processes to exclude" portion of an AP rule.
In our own testing of the feature pre-release we saw no such issue; had we done so we would've investigated prior to releasing the patch (reason #1 why we experience schedule delays). But that fact tells us, with respect to your own experience, that there is something more to this issue than simply having an exclusion.
This alone is reason to _not_ pull the patch, because you'd be affecting all customers based on the unconfirmed report of one. I open myself to 2 possible lashings there in saying it's unconfirmed and that there is one report only. So let me tackle those real quick -
What do we know is that 1 report (or even 10 for that matter) for a behavior that isn't immediately apparent is not sufficient cause to make a judgment call that affects everybody; so the patch is not being revoked.
We also know it is a behavior that does need investigating, it needs to be understood with all its nuances (and mitigating factors if it is a bug) because it is impacting at least 1 customer. This is in progress. And as stated earlier, we'll update our Known Issues KB article if there's a bug here. We might need to update the article even if it's not a bug. We'll see.
What we might learn from this is that our testing should be expanded to include your scenario - I'm sure management types will clue in on that one.
Something I've learned from this is that Access Protection continues to be one of the least understood features of VirusScan Enterprise - because you sought to downgrade the software over this issue, rather than disabling a single AP rule and wait for the behavior to be researched; that's like finding out you have a tooth cavity and opting for a complete set of false dentures to fix it, then asking for the cavity to be looked at. Total overkill! But maybe it's because you found yourself in a desperate situation, which I think you alluded to earlier that had you been the one in control there would have been more testing done beforehand, but immediate action had to be taken instead of spending time looking for a workaround. That all makes sense to me. Even so, it still tells me that this Access Protection feature is not well understood because the knee-jerk response was to downgrade instead of looking at the Access Protection log file, or the Events coming in from ePO, telling you which rule was being violated... which would let you know the simple option was to disable that rule. (So, for everyone who's reading this: Please read my Blogs )
And I haven't forgotten your comment about this being reported months ago. I still think folks are going to be kicking themselves for that if this is confirmed to be a bug. I have some input there for when that comes up as an internal discussion, believe me.
And to your final question, a fix cannot be had until a) a bug has been found, and b) a fix is deemed plausible, and then c) a fix is deemed necessary. For customer-impacting issues if (b) is possible then (c) is a given; the question then becomes "when".
The behaviour is confirmed , I even told you guys exactly how to reproduce it. Using 1 PC , no ePO needed. It literally takes 5 minutes.
McAfee Benelux confirmed it but they also don't seem to get through.
We can NOT disable the AP rule because most of our protection depends on that rule, so yes , we downgrade. It has nothing to do with not understanding the AP. This rule is the only way we can prevent the users to install random software as they have no other restrictions on their PC.
If they don't understand the problem by now over there, I think we better look out to migrate to another vendor for our security. I'm done trying to explain this simple to reproduce bug.
I am a McAfee admin since 1993 and over these years I encountered a couple of problems/bugs which were handled/solved when we contacted McAfee. Since Intel took over it seems we first have to get through 3 layers of Indian callcenters, obnoxious americans and service departments that doesn't seem to know how to install their own product...
And if you dare to say that a bug cannot be found, I think it is time I expand this to the social media where this gets more visibility . Maybe that's something that wakes them up in the ivory tower over there.
McAfee support often depends on the service technician who has the ticket. We are Elite Partner and we are SIA Partner. Really often, if we open a service case, Gold Support does not understand the problem. I really understand .
Actually several Customers tested Patch 5. This Patch is NOT USEABLE!!
- Upgraded some systems in our LAB. After upgrading a system from Path 4 to Patch 5 the system is not working any more.
- If there are several McAfee Products installed on the endpoint, Patch 5 damages the system.
- Some customers expect error messages with Patch 5 and Winword. After Patch 5 installation they are not able to store directly on a UNC share (explorer process crashes)
- At the moment we have absolutely NO customer where Patch 5 works without troubles.
I have one environment where Patch 5 works fine. This is a new windows installation where only VSE P5 is installed. Any upgrade procedure failed.
I´m also working with McAfee Products since 1998. And it really sucks when anyone tell you how a McAfee product (VSE has not changed the last years) works, giving you the feeling not knowing how to enable access protection.
Therefore i fully agree with paradriod. From a McAfee Partner perspective we are informed our customers not to use Patch 5.
Cheers
Corporate Headquarters
6220 America Center Drive
San Jose, CA 95002 USA