[Pkg-clamav-devel] Bug#884707: apparmor breaks clamdscan
Francois Gouget
fgouget at free.fr
Thu Feb 1 20:15:56 UTC 2018
On Sun, 7 Jan 2018, intrigeri wrote:
[...]
> The alternatives are not very compelling, they are
> basically: either give up on path-based LSM entirely or make the
> AppArmor policy wide enough to accommodate all kinds of needs; in both
> cases, we lose security benefits of the majority of users for whom the
> current profile would work just fine, which is sad.
I don't see how the AppArmor profile improves security.
I assume the goal is to either prevent remote attacks, local privilege
escalations or limit damage after a compromise.
For a remote attack the exploit is likely to come in the form of an
email attachment or a link to a malicious file that will get saved to
~/Downloads. Both locations are allows by the AppArmor profile so that
these exploits will reach their targets (clamd). Plus, as pointed out
before, any file saved in a location out of reach of clamd will instead
be able to attack the user account without risking detection.
For a local privilege escalation, the attacker can simply use --fdpass
to bypass the path-based AppArmor restrictions. So again the Apprmor
profile provides no benefit.
So now what about mitigating the damage that can be done by compromising
the clamd process?
What kind of damage can be done?
* Making the clamd process inoperative so other exploits can slip
undetected.
-> The AppArmor profile cannot prevent that.
* Leaking sensitive files.
-> The clamd process runs in the clamav account and thus does not have
more privileged access to sensitive files than any other accounts
with the exception of the clamav files. But the AppArmor grants
read access to all the clamav files so it does not help here
either.
* Poisonning the clamav virus database to disable it.
-> The AppArmor profile allows write access to the /var/lib/clamav/*
files which, if I understand correctly, is where the virus database
files are. So it does not help for this either.
* Using clamd to perform other system attacks.
-> The system vulnerabilities are not going to be more exploitable
from the clamd process than from any other user account. So the
AppArmor is no help for local privilege exploits but could help
mitigate the damage caused by remote attacks.
-> That's as long as users use clamd rather than clamscan which is
not protected by any AppArmor profile.
I think the basic mistake is treating clamd as if it was a web or
database server. Database servers are supposed to only use a very
limited set of files so an AppArmor profile limiting them to that set of
files makes sense.
But the whole purpose of an anti-virus is being able to check *any* file
on the system. Any place that the anti-virus cannot check is a place
that an attacker can use to put an exploit that won't be detected. That
was a big part of the issue with the Sony rootkit. That ClamAV is doing
it to itself makes it no better.
The profile would make sense if clamd is only used remotely rather than
to scan local files.
--
Francois Gouget <fgouget at free.fr> http://fgouget.free.fr/
Nouvelle version : les anciens bogues ont été remplacés par de nouveaux.
More information about the Pkg-clamav-devel
mailing list