Clamscan vs clamdscan

(Crazy there is antivirus but not clamav)

Fedora has clamd in it’s repos.

ClamAV has a COPR repo and in there you find the clamav package.

Afaik clamd is more resource efficient and suited for background usage?

I got a malware file once, and clamscan detected it, clamdscan didnt.

Mind to enlighten me?

1 Like

clamscan

  • An app to scan fils/dirs directly.
  • Runs with user permissions, can be elevated.
  • Uses unconfined SELinux context.
  • Loads the DB each time it starts.
  • Performs single-threaded scanning.

clamdscan

  • A client interface for the scanning service.
  • Runs with service permissions, configurable.
  • Uses confined SELinux context.
  • Keeps the DB in memory.
  • Allows multi-threaded scanning.

Additional notes for clamdscan:

  • The user should join the virusgroup to use the tool.
  • Requires the clamd service to run and listen on the socket.
  • Scanning the whole filesystem:
    • Requires an explicit config change to elevate the privileges.
    • Requires an explicit SELinux boolean modification.
    • Apparently triggers some dontaudit rules:
      • Still fails to access certain files without denials.
      • Works in permissive SELinux mode.

See also: Use clamdscan on workstation F38 - #3 by vgaetera

1 Like

The 2 biggest differences between clamscan and clamdscan is that clamdscan can scan for malware using multiple parallel threads where clamscan is single-threaded. Also, clamdscan can be used by things like mail servers (via a milter) to scan email as the mail server receives it. For the difference in detection you experienced, make certain you run freshclam to get the most current virus/malware signatures.

2 Likes

There are ways to open a Fedora workstation to infection.

Activating the root account during installation and later running as root while a browser is in use presents opportunity for a crafty bad actor to add and/or modify files as only root should be able to. If closing your browser is inconvenient, consider using “sudo” to gain elevated permission when required.

Do not enable the root account during installation but DO add the first user (your account) as administrator. Then the “su -s” and “su -i” commands will prompt for YOUR password before granting elevated permission.

If, after the installation has completed, you want to run a bash script located in your home directory as root using the local environment, the command “su -s” will temporarily elevate your session to root so that script can run.

Close the terminal after script execution completes. Caution would dictate closing the browser before issuing the “su -s” and keeping it closed until the terminal window where the script was run has been closed.

I follow these steps and have never had a hacking problem during the past decade as a Fedora workstation user even though there have been many times when I ended up on an unsavory site when I clicked on what should have been an innocent link from a google search. After such an encounter. I usually cleared the browser cache,

Anecdotal evidence has convinced me that Fedora workstation WILL successfully defend against bad actors as long as I run with user rather than root privilege.

Thanks but no idea how this is relevant to the thread.

You can easily get malware without running stuff as root

For a home user at least, root isn’t that important.

There’s an xkcd for this, as always.

2 Likes

Anyways, antivirus is no good primary solution for security.

Most of my malware detections were for Windows malware attached to emails that were not detected with current signatures when first delivered, but were detected months to years later after re-running clamscan with newer signatures.

1 Like

Hi George,

Not surprising :slight_smile: I’ve encountered the same thing … thankfully I rarely run anything that can exec code written for Microsoft Operating systems. As for *nix/Linux, I avoid running anything as a privileged user and I mount my home directory (noexec) such that executables are not allowed. And I use SELinux as well :slight_smile:
(Yeah, I’ve been at this a while … since the 1980’s)

2 Likes

Hi Jasper,

LOL … Yes there is !!!

Can you explain how you mount your home directory like that? Do you do this on default Fedora BTRFS partitioning in /etc/fstab? Or do you need a separate home partition for that?

I want to make a conversion script, that moves all scripts and programs to /usr/local/bin and does the same. nusuid may also be important, just to be sure.

Hi boredsquirrel,

IF you already have an entry in /etc/fstab that looks something like this:
UUID=cdf57162-3fb6-4d5c-828b-a657cc284d8c /home ext4 defaults 1 2
THEN just add ,nosuid,noexec like this…
UUID=cdf57162-3fb6-4d5c-828b-a657cc284d8c /home ext4 defaults,nosudi,noexec 1 2

From Scratch:
Preparation — you need to do all these steps as root and you need to have a disk partition available

Begin step-by-step:

  1. You are going to need a partition on your disk for /home (mine is /dev/nvme0n1p4)
  2. format it to your preferred fs (mine is ext4 but can be btrfs, xfs …)
  3. to keep from overlapping an existing /home, temporarily make a directory /mnt/a and mount your new/fresh partition on /mnt/a (mount /dev/{disk_partition} /mnt/a)
  4. rsync the existing /home to the new partition (rsync /home/ /mnt/a) …when completed double-check the destination to verify all the data is intact :slight_smile: )
  5. umount /mnt/a
  6. rm -rf /home/* — make sure to leave just /home as an empty directory
  7. mount your new partition (mount/dev/{disk_partition} /home
  8. in etc/fstab – add the following
    /dev/{disk_partition} /home {fs_type} default,nosuid,noexec 1 2
  9. save fstab and mount /home or reboot

NOTE(s):

  1. Yes, In my setp-by-step I did not use UUID in favor of just simply using the device…
  2. Once noexc,nosuid are in effect, you should not be able to exec/run anything from the home directory … not even as root. To add belt-and-suspenders, setup selinux to disallow the same conditions on /home.
  3. Yes, you can do this with a second disk if you choose
1 Like