Thunar , Firejail and a custom RMB "on-demand" scan

Hello Irvine McMinn,

you just check the contents of AvTestResult, it'll be empty not only if no virus has been found but also when savscan encounters an error (while attempting to access or during scanning a file), returns an error, or even fails to run. Can't say which on is the case but, obviously, it looks like it's caused by the sandbox.

To your other question: but not the other test samples. Which test samples? Please note that while an AV is supposed to detect real threats you can't expect that it detects some arbitrary test sample. even though the author thinks the sample looks like the real thing. The scanner might simply (and correctly) determine that it is actually innocuous.

Christian

Thanks for your reply, it gave me some ideas to try, and I think I have figured this out:

1. Firstly, from inside the shell, I tried piping the savscan output to a DebugFile, which, when piped from a sandboxed Thunar instance, was empty. ie no content
2. Next, again from inside the shell, I copied a test virus form my Downloads folder to my Desktop. This worked even when the Thunar instance was sandboxed

Giving #2 a bit of thought, I realised I also needed to pipe stderr to the DebugFile, so I added the following to the shell

DebugFile=$(savscan -f -all -archive -loopback -pua -suspicious $1 2>&1 )
echo $DebugFile > "/home/stupidme/Desktop/ThunarAvScan--Debug"

This resulted in the following error message: Error: Unable to locate SavForLinux installation directory. Which was interesting, since /opt/sophos-av/ is not specifically blacklisted.

After further experimentation, and looking at the default Thunar profile for Firejail, all of the following rules are likely sources of the problem:

caps.drop all
nonewprivs
noroot
seccomp

In particular, since accessing /opt/sophos-av/   involves escalating privileges, seccomp and nonewprivs will kill savscan. 

As a result, I am now fairly confident that the only way to run an on-demand scan from a sandboxed instance of Thunar would be to significantly weaken the default Thunar profile.

By the way, "the other test samples" referred to eicarcom2.zip, eicar.com.txt, and eicar_com.zip

Once again, thanks for your reply. It was surprisingly helpful.

 Irvine

Hello Irvine,

so the other EICAR samples. Well, on-access is likely not configured to scan inside archives (please see chapter 15.4 in the Configuration Guide). My tests show that it does detect (and block the open of) the "plain" EICAR in a file regardless of the extension though.

weaken the default Thunar profile
likewise I wouldn't change the permissions on and in /opt/sophos-av/. Are you interested in doing additional scanning or do you intend to turn on-access scanning off? You've probably noticed that running savscan is expensive as it has to load and initialize all the scanning data.

Christian

Hi. thanks again for your interest.

On-access scanning: Yes, default on-access scanning is configured for a limited number of file types, but since many/most of my downloads are either archives or videos, I am more concerned with configuring an easy method of scanning downloaded files. Basically, for software, I only use the official Arch Linux repository and the peer reviewed AUR. In fact, currently, Sophos is the only software I have that does not come from these two sources. Having said that, since I maintain a number of AUR packages, I regularly compile and test software from upstream sources. As a result, implementing a RMB on-demand scan for Thunar would have been very practical. 

/opt/sophos-av/ permissions:  I was not suggesting changing the permission for the sophos-av folder, and completely agree that it would be an incredible stupid idea. What I was suggesting was that it would be fairly easy to weaken Firejail's Thunar.local profile to permit privilege escalation inside the Thunar sandbox. Having said that, while permitting privilege escalation is occasionally necessary when sandboxing applications, (for example: ping,)  the Thunar file manager is is a primary attack vector. So, again, weakening the Thunar sandbox would be another very stupid idea.

On-access scanning is expensive on system resources: Oh, you have no idea. I don't know if you are familiar with *nix operating systems, but they ignore file extensions and instead rely upon reading the first few lines of a file to determine it's type. Similarly, lightweight file managers like Thunar don't keep indexes, and instead rely upon an on-access scan of each folder to discover it's contents. As a result, occasionally, when using Thunar's drop-down navigation menus for the xfce-panel, you can accidentally cause sophos-av to scan the /lib/ folder. For the uninitiated, this a real PITA. /lib/ contains 10's, if not 100's, of thousands of executable libraries similar to Window's dll's. Of course, the solution here is not to have a drop-down navigation menu for the root folder.

Switching on-access scanning off: In view of the above, this is a definite possibility for which I am still weighing the pros and cons. As I see it, given my usage, all I really need is a regular scan launched by systemd  and un-sandboxed on-demand launchers to scan selected folders like $HOME/Downloads/, /tmp/, and $HOME/Git/,  (my build folder.)  As I say though, I am still weighing the pros and cons of this approach and your views and opinions are welcome.

Irvine

Hello Irvine,

yes, the accesses can be a drag. The scanner tries to keep a cache to avoid unnecessary rescans but this nevertheless causes more than some overhead.

Can't say if DouglasLeeder has some suggestion.

Christian

I'm afraid I can't suggest anything: savscan is setuid so that it can report results to savd, but there isn't any way to configure it to not be setuid.

Could SAVDI used to do on-demand scanning but avoid the overhead of savscan? Or would it also not work in the sandbox? Just curious.

Christian

Hello again, I have added a panel launcher to my box offering a menu of on-demand scans for critical folders, but am still weighing the pros and cons of switching off on-access scanning. Looking at section 15, Configuring on-access scanning, of the configuration guide, I noticed that there was a section about excluding file types and have a couple of questions:

1. Is it possible exclude problematic folders, (like /lib/,) from an on-access scan?
2. If so, are they also excluded from a full system scan?

With regard to savscan's setuid bit: I haven't tried it, but technically it should be possible for ${USER} to join the sophosav group. I believe, but am not certain, that this would then allow savscan to run inside the Thunar sandbox. Once again though, this seems a bit like locking the door while leaving the key under the flower-pot.

Using SAVDI for on-demand scanning: I had a look at the developers guide for SAVDI. It didn't specifically mention anything about the setuid bit, but, if I was a betting man, I would bet that SAVDI would have similar problems with escalating privileges as savscan.

Thanks again for your interest, you are giving me some useful ideas.

Irvine

1. Yes, you can exclude paths from scanning: /opt/sophos-av/bin/savconfig exclude /lib/

2. On-access exclusions are separate from scheduled scan exclusions and both are separate from command-line scans.

Just a reference summary for anyone with similar problems/questions:

1. It is possible to easily add an RMB scan-on-demand  launcher to the context menu of the un-sandboxed Thunar file manager
2. However, if the file manager is sandboxed, then the required privileged escalation should kill savscan, otherwise I would recommend checking the configuration of your sandbox.
3. Additionally, if you are using a security sandbox like Firejail, a working alternative to a context menu launcher is to create a panel launcher for a shell  to allow copy/pasting a path to the file or folder you wish to scan.
4. Further, using inotifywait, it should be possible to detect the completion of a download and automatically launch a customised scan. The exact details of this are way beyond the original scope of this thread. But, since it's the next feature I intend to implement, I should point out that I do not expect it to take more than a couple of hours and suspect that the final shell will be only a few lines long.
5. Finally, for reference, I am leaving on-access scanning active. But, because I make extensive use of the Xfce panel's navigation menu's, I am excluding large/problematic folders like /bin/ and /lib/ from on-access scanning. Note, these folders are still being scanned during systemd's scheduled scans.

Once again, thanks for your interest. It has helped me focus on the nature of the problem and what it is I wish to achieve.

Irvine