Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
- Loading branch information
Signed-off-by: Heinrich Schuchardt <xypron.glpk@gmx.de>
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why did you add
cifs? Does it just not work?!I also added the following filesystem types to the default /etc/skyldav.conf of my Gentoo package:
What do you think about that?
Cheers,
Wolfram
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I enabled scanning for a CIFS mount. I tried to copy 7 files of ca. 1MB each to the mount. This drove my system to near standstill for minutes. With scanning disabled for the mount copying was done in less than a second.
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm. CIFS running as a daemon, what does that mean?!
I only know about regular mounted CIFS filesystems using the kernel CIFS filesystem support, for example when accessing Windows or Samba file servers.
There's a certain danger that contents from remote filesystems could contain malware, so not scanning these does not seem wise to me.
Why do you think that standstill you described was happening at all?
Regarding the excluding of
devtmpfs, devpts, debugfs, configfs, securityfs, cgroup, rpc_pipefs: I excluded them because they are special filesystems created by the kernel itself (like procfs), so I doubt they could contain malware at any time. Hmm,autofscould also be added I believe.Cheers,
Wolfram
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Heinrich? :)
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ping :-)
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For the following file systems it is definetly possible that user space creates malware content:
devtmpfs:
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=2b2af54a5bb6f7e80ccf78f20084b93c398c3a8b
"Devtmpfs can be changed and altered by userspace at any time, and in any way needed - just like today's udev-mounted tmpfs."
The following works for me:
sudo su
cat << EOF > /dev/doevil
Evil I will do.
EOF
cat /dev/doevil
configfs:
The file system is meant to be written to from user space. Cf.
http://lwn.net/Articles/148973/
63b01b9There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hence Skyldav ends up in an infinite recursion, depleting system memory.
For EXT3/4 this does not occur because ClamAV reads with the process ID of Skyld AV and files read with this process ID are not scanned by Skyld AV