clamdscan says Access denied. ERROR on all files

Hi

The problem could be that clamdscan uses clamav daemon to scan for files, but clamav daemon runs with user clamav, which doesn't have acces to your files in /home/imi (because /home/imi has 0700 permissions probably).

You could consider using clamscan instead of clamdscan for scanning files in /home.

If you _really_ want to scan your home with clamdscan you could do something like this:

- usermod -a -G imi clamav (this puts clamav user in the 'imi' group)

- chmod 0750 /home/imi (this gives group read permission in your home directory, so anybody who is in 'imi' group can open/read the directory)

- /etc/init.d/clamav-daemon restart

I can't comment on the possible side-effects though :)

I had the same problem on my Ubuntu Jaunty system:

chrisb@ernie:~/fixtures$ clamdscan
/home/chrisb/fixtures: lstat() failed: Permission denied. ERROR

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.002 sec (0 m 0 s)

The permissions on that directory, and all parents, should allow access:

chrisb@ernie:~/fixtures$ ls -ld /home /home/chrisb /home/chrisb/fixtures
drwxr-xr-x 9 root staff 4096 2009-03-20 17:31 /home
drwxr-xr-x 163 chrisb chrisb 61440 2009-10-20 13:09 /home/chrisb
drwxrwxr-x 2 chrisb staff 4096 2009-10-20 12:51 /home/chrisb/fixtures

Running the same test on a Debian system is fine, which led me to check the diff between Ubuntu and Debian clamav packages. The main one I noticed was that apparmor is enabled on Ubuntu. Sure enough, that's the problem:

chrisb@ernie:~/fixtures$ sudo /etc/init.d/apparmor stop
 * Unloading AppArmor profiles
   ...done.
chrisb@ernie:~/fixtures$ clamdscan
/home/chrisb/fixtures/eicar.com.txt: Eicar-Test-Signature FOUND
/home/chrisb/fixtures/eicar.com: Eicar-Test-Signature FOUND
/home/chrisb/fixtures/eicar_com.zip: Eicar-Test-Signature FOUND
/home/chrisb/fixtures/eicarcom2.zip: Eicar-Test-Signature FOUND

----------- SCAN SUMMARY -----------
Infected files: 4
Time: 0.004 sec (0 m 0 s)

It looks like the default apparmor profile is restricting the files that clamd can read, which totally breaks clamdscan.

I'm not sure why you're scanning your home folder with clamdscan, instead of clamscan (which would work by default).

Apparmor is supposed to restrict clamd acces, that's what it's for I guess. You can always add the directories you want to scan with clamdscan to clamav-daemon's apparmor profile (/etc/apparmor.d/usr.sbin.clamd).

What if someone added the following to /etc/apparmor.d/usr.sbin.clamd:

  owner @{HOME}/ r,
  owner @{HOME}/** r,

Then ran:
$ sudo apparmor_parser -r /etc/apparmor.d/usr.sbin.clamd

This should allow someone to scan anything under their home directory.

That's what I said, you can add exceptions to apparmor, you can clutter it up with a bunch of folders OR you can 1. add the root folder to it (/**), which kinda defeats apparmor's purpose, or 2. you could use clamscan for scanning arbitrary folders manually.

It all depends on what you want to do exactly. If you're scanning your home dir once a day from say crontab, then there's no point in running clamav-daemon in the background (IMHO).

It may not be the best way to do it, but I don't think there is a security
benefit to denying access to the home dir of the user calling it.

These lines should be relatively safe because it provides 'r' access only. This does gives access to sensitive files such as ~/.gnupg and ~/.ssh though.

The question is whether or not this would work with 'owner'. I was assuming clamdscan would be the one needing the access, but in retrospect it may be that clamdscan just feeds the paths to clamav. We need the apparmor denied messages from /var/log/kern.log to know for sure.

Is using clamdscan in this matter normal?

The only possible benefit I can see in using clamdscan over clamscan is the speed. When using clamdscan, that's actually using the running clamav-daemon, which has preloaded database, so startup is a bit faster. But beside that, clamdscan/clamd is usually used for stuff like integrating in MTA scanning and such, not for the user to scan stuff manually.

Of course it CAN be used that way, too. One can set clamd up to run in the background and use clamdscan to send it file/directory paths to scan. That's where apparmor (if it's runinng) comes in, and restricts access.

Actually, I was just using my homedir as an example. I was actually debugging an issue that a colleague of mine was having with interfacing with clamd in a web application. A quick googling suggests that this issue is causing problems for quite a few people - it's certainly not very user-friendly, and the security benefits are questionable. clamd is already running as a normal user, so shouldn't be able to access sensitive files anyway. I'm not sure what the point is of locking it down further - at least, not by default.

The clamdscan manpage describes clamdscan as:

       clamdscan is a clamd client which may be used as a clamscan replacement.

If you're going to lock down clamd in this way, then this is incorrect, and the manpage should be updated to reflect this.

It's not clamd that is locked down specifically, it's because of Apparmor, which restricts a lot of things if running.

You can choose not to use Apparmor, or as said above, you can modifiy clamd's Apparmor profile to include those directories you need to scan. I'm pretty sure that Apparmor restricts other applications, too, not just clamd.

Maybe Jamie has some other advice or explanation for this whole Apparmor thing, but I'm thinking:

By default clamd's profile contains all the exceptions (if not all, then 99%) for all the default included applications in Ubuntu which use clamd (take a look at /etc/apparmor.d/usr.sbin.clamd). For anything else 'custom', you have to reconfigure Apparmor to use clamd with that particular application. That hardly qualifies as a bug in clamav or Apparmor. It just needs tweaking. IMHO.

The security benefit is not questionable-- clamav has historically had *many* CVEs, some of which result in arbitrary code execution. AppArmor mitigates this risk of running clamav and protects the user from known and as-yet-unknown vulnerabilities in clamav.

The AppArmor profile is intended to work in common usage scenarios, and if this is a common usage scenario, then perhaps adding:
  /** r,

would be ok. I'll let the clamav maintainers decide if this is worth it. Keep in mind, only DAC will protect against arbitrary reads, and since clamav does run as its own user, this should be enough for the sensitive files I mentioned, /etc/shadow, etc. This still protects against arbitrary could execution, but does weaken the profile somewhat.

Chris mentioned that people are having quite a few problems with this. This is the first bug I've seen against clamdscan. If people want these things fixed, they must let developers know by filing bugs.

Perhaps then what is needed is some linkage in the clamscan man page to
apparmor (since it isn't obvious if you don't know). Given clamav's
security history we do not want to run it unconfined and we don't want
people to turn off apparmor.

Uploaded and waiting for release team review. The documentation should be better, but at least this is a start. Patches welcome.

This bug was fixed in the package clamav - 0.95.2+dfsg-4ubuntu4

---------------
clamav (0.95.2+dfsg-4ubuntu4) karmic; urgency=low

  [ Scott Kitterman ]
  * Apparmor profile fixes (reviewed by Ubuntu Security):
    - Allow clamav-daemon access to the home directory of the user running it
      and update README.Debian to explain the need to adjust the apparmor
      profile for it to scan elsewhere (LP: #450250)
    - Add capability dac_override to clamav-daemon profile to allow
      AllowSupplementaryGroups to work (LP: #433764)
  * Cherry pick packaging bug fixes from pkg-clamav git

  [ Stephen Gran ]
  * Make all references to the milter socket reference the same path
    - b71e1a26bafb0df532df2673fcd1cd53bc6952bd
  * Read default file once (LP: #430421)
    - 86b421dac00e49abb8e5907b9e952e33e83b7aec

  [ Michael Meskes ]
  * Fixed LSB header information. (Closes: #546450) - thanks to Petter
    Reinholdtsen <email address hidden>
    - 3f59d827d1e54ce1efcb7e050c57866ccdfaedae

  [ Michael Tautschnig ]
  * Remove all remaining files during purge
    - 4132426753b674dd9c622f1c0501703ed987a239

 -- Scott Kitterman <email address hidden> Sat, 24 Oct 2009 12:34:00 -0400