Comment 7 for bug 1802498

On Wed, Nov 14, 2018 at 09:03:13AM -0000, Rami Hakim wrote:
> When ESET v4 was released , AppArmor wasn't available back in the time
> it wasn't developed yet.

While ESET the company predates AppArmor, AppArmor predates this specific
version of ESET NOD32 :)

https://web.archive.org/web/20000818164529/http://www.immunix.org:80/documentation.html#codomain

(Back in the 90s AppArmor was known as "CoDomain" and "SubDomain"
and started life as the "mighty morphin[g?] file system".)

> I'm not that experienced with AppArmor , but I think if one can properly
> configure AppArmor to work with ESET , it will work as far as I can
> imagine.

Probably yes, at least if ESET's code injections are relatively
straightforward and don't do anything too surprising. Policies will need
to be adapted to adjust for the injected code, but that's just the way it
is. Used resources must be enumerated.

> But the problem is from ESET's side , so they have made a program that
> doesn't work with SELinux , and not compatible with AppArmor.

I suspect the story on SELinux is similar -- they "just" need to modify
policy to recognize that all domains can communicate all types to the ESET
scanner. It would probably also require modifying policy to allow the code
injection to work in all domains.

> I've been on this problem for a while now , and it seems that ESET is so
> quiet about any replies, So I wonder if Ubuntu team will take a look at
> this problem, I would be very glad if someone fixes it , even if it was
> a workaround but atleast a fix.

We're happy to address specific DENIED messages (though the apparmor mail
list would probably be the better venue) but are unlikely to prioritise
actually installing and configuring ESET ourselves.

https://lists.ubuntu.com/mailman/listinfo/apparmor

We're also unlikely to modify our default policies. The tradeoff between
MAC policy and AV is best made by individual sysadmins.

Thanks