clamdscan says Access denied. ERROR on all files

Reported by Imre Péntek on 2009-10-13
This bug affects 5 people
Affects Status Importance Assigned to Milestone
clamav (Ubuntu)
Jamie Strandboge

Bug Description

Binary package hint: clamav

Hello, I don't know what's the problem really is, let's see a session:

imi@most:~$ cd Asztal/
imi@most:~/Asztal$ clamdscan words.txt
/home/imi/Asztal/words.txt: Access denied. ERROR

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.008 sec (0 m 0 s)
imi@most:~/Asztal$ ls -ladh words.txt .
drwxr-xr-x 16 imi imi 4,0K 2009-10-13 12:19 .
-rw-r--r-- 1 imi imi 2,5M 2009-09-21 15:40 words.txt
imi@most:~/Asztal$ cp words.txt ..
imi@most:~/Asztal$ cd ..
imi@most:~$ clamdscan words.txt
/home/imi/words.txt: Access denied. ERROR

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.008 sec (0 m 0 s)
imi@most:~$ ls -ladh words.txt .
drwxr-xr-x 65 imi imi 4,0K 2009-10-13 12:42 .
-rw-r--r-- 1 imi imi 2,5M 2009-10-13 12:42 words.txt
imi@most:~$ rm words.txt
imi@most:~$ cd /tmp
imi@most:/tmp$ cp /home/imi/Asztal/words.txt .
imi@most:/tmp$ clamdscan words.txt
/tmp/words.txt: OK

----------- SCAN SUMMARY -----------
Infected files: 0
Time: 0.350 sec (0 m 0 s)
imi@most:/tmp$ ls -ladh words.txt .
drwxrwxrwt 19 root root 4,0K 2009-10-13 12:43 .
-rw-r--r-- 1 imi imi 2,5M 2009-10-13 12:43 words.txt
imi@most:/tmp$ LANG=en_US id
uid=1000(imi) gid=1000(imi) groups=4(adm),20(dialout),24(cdrom),46(plugdev),106(lpadmin),121(admin),122(sambashare),1000(imi)

ProblemType: Bug
Architecture: i386
DistroRelease: Ubuntu 9.04
Package: clamav-daemon 0.95.2+dfsg-4ubuntu1.2
 PATH=(custom, user)
SourcePackage: clamav
Uname: Linux 2.6.28-15-generic i686

Related branches

Imre Péntek (pentek-imre) wrote :
Imre Gergely (cemc) wrote :


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.

Imre Gergely (cemc) wrote :

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 :)

Chris Butler (chrisb-debian) wrote :

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
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.

Imre Gergely (cemc) wrote :

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).

Jamie Strandboge (jdstrand) wrote :

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.

Changed in clamav (Ubuntu):
assignee: nobody → Jamie Strandboge (jdstrand)
status: New → Incomplete
Imre Gergely (cemc) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

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?

Imre Gergely (cemc) wrote :

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.

Chris Butler (chrisb-debian) wrote :

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.

Imre Gergely (cemc) wrote :

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.

Jamie Strandboge (jdstrand) wrote :

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.

Scott Kitterman (kitterman) wrote :

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.

Scott Kitterman (kitterman) wrote :

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

Changed in clamav (Ubuntu):
status: Incomplete → Fix Committed
Launchpad Janitor (janitor) wrote :

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

Changed in clamav (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers