[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