Linux Security 7 is now out and with it is a new version of Security Platform, v. 2.0. Security Platform is our scanning core. It contains the scanning daemon and everything else related to malware detection.

The scanning daemon, fsavd, has some new settings. These did not make it to the LS7 manual, mainly because we did not think too many people would be interested in peeking under the hood.

For those who are interested, here are the details:

First setting:
F-Secure Security Platform / Settings / Advanced / Archive Settings / Maximum archive size to decompress into memory (1.3.6.1.4.1.2213.48.1.100.10.10.10)
Any archive smaller than this size will be decompressed in memory while it is scanned. The default value is 50 MB. Valid values for this setting are 1 - 8000 MB

Second setting:
F-Secure Security Platform / Settings / Advanced / Archive Settings / Maximum archive size to decompress into temp file (1.3.6.1.4.1.2213.48.1.100.10.10.20)
Any archive larger than previous setting will be decompressed into a memory mapped temporary file. The default value is 100 MB. Valid values for this setting are 1 - 80000 MB.

These settings allow the user to fine tune the speed of scanning archives. Archive scanning is essentially a function of how much memory can be allocated to the task. Scanning is fastest when the whole archive can be decompressed into memory for scanning. Users can now allow fsavd to take as much memory as they feel comfortable with.

Some archives are so big they will not fit into memory. Those archives will be decompressed into a temporary file, which is mmap’ed in the scanning daemon. The 2nd setting specifies the maximum size for that temporary file.

We do scan archives even larger than can fit into the memory mapped temporary file, but that might be considerably slower because only a part of the archive can be decompressed at a time and might even need to be decompressed again if later analysis requires a part of the file to be re-examined.

In a nutshell: archive scanning is a compromise between speed and size. If you have lots of memory, you can have fast archive scanning. If you do not have a lot of memory but have a lot of disk space, you can have reasonably fast archive scanning. If you have neither, you are going to have slow archive scanning.

Third setting:
F-Secure Security Platform / Settings / Advanced / Archive Settings / Directory for temporary files (1.3.6.1.4.1.2213.48.1.100.10.10.30)
This setting specifies the directory where the memory mapped temporary files are created. The default directory is /tmp. The temporary files are unlinked immediately after they are created, so you will probably never see the files.

If you never want fsavd to create temporary files, set the 2nd setting equal to the 1st setting. Then all archive decompression will happen in memory.

Fourth setting:
F-Secure Security Platform / Settings / Advanced / Archive Settings / Maximum allowed compression ratio (1.3.6.1.4.1.2213.48.1.100.10.10.50)
Some archives do not contain real files but are maliciously constructed to cause havoc in an AV scanner by blowing up to an extremely large size. This setting allows fsavd to protect itself by issuing a scanning error for archives which have very large compression ratio. The default maximum compression ratio (decompressed size / compressed size) is 1000. Valid values for this setting are 1 - 1000.

Today we are proud to present a major piece of quality software, which we have improved, tested and polished with all of our skill, understanding, passion and love for the past 11 months. The release of Linux Security 7.00 has arrived. I’d like to highlight some of the improvements here:

• New web-based wizards have been added for manual scanning and configuring the integrity checking and rootkit protection features.
• A simplified, cleaned-up installer with less questions asked.
• A new kernel-level scanning result cache significantly improves the performance of on-access scanning.
• The new F-Secure Scanning Engine has been integrated.
• We added methods to completely disable specific components of the product, like the firewall or the web user interface. If you prefer using your distribution’s firewall configuration method, we will not interfere with it. If you prefer to not use the web user interface, there is no need to burden your system with it’s Java run-time environment.
• Firewall rules can now be applied to specific network interfaces.
• The F-Secure Gnome panel applet now notifies you of any security alerts.
• The client and server edition installer packages have been merged into a single installer to simplify distribution and installation. On the other hand, new 64-bit installer packages have been introduced to fully support new 64-bit distributions. Some things simply wouldn’t work with 32-bit compatibility libraries.
• If you’re still running F-Secure Antivirus for Linux 4.65, it’s now possible to upgrade to Linux Security 7.00 in command-line-only mode. If command-line scanning is all you need, this is for you.
• If you wish to integrate F-Secure’s cutting-edge scanning features with your own software, the Linux Security 7.00 release package contains an SDK for our daemon API, full with header files, a manual page, and example code in the C language.

With a large number of new Linux distributions added and a couple of old ones removed, this release is officially tested and supported on 33 different distribution versions. It should work on a few others, too, especially if installed in command-line-only mode.

Unfortunately the native Gnome scanning application, fsgav, had to be dropped before the release. Don’t worry, it will probably re-appear in a future version, once we’ve had time to smoothen it’s sharp edges a bit.

A full list of new features, changes and supported platforms can be found in the release notes. Please download your evaluation copy here:

As usual, the software can be evaluated for free for 30 days.

UPDATE: this build has been recalled. More information will be available here shortly.

If you wish to purchase licenses for your business, please get in touch with one of our sales partners or regional offices. End-user licenses should be available in the F-Secure eStore in the near future.

We have been very busy recently (aren’t we always?) because we are preparing the final release of Linux Security 7. Even though we try our best to be agile and use Scrum, things still seem to speed up towards the end when every string is tied and every surface polished. We are excited about this release. Linux Security 7 has a number of new features and fixes we are sure you will like.

Last week I wrote about the importance of one command build. Among other benefits, it makes it easy to automate the build. And when you have an automated build, you can run the build as often as you want.

Why would you want to build often? Let me tell you…

Five years ago I worked in a team where we had a weekly build on Thursday afternoon. Every developer worked on their own module from Monday to Thursday morning and then did cvs commit. Then the Build Master made the build and invariably it failed to compile. Then the Build Master figured which developer to blame for the compilation failure and the poor developer tried to frantically make his code co-exist with all the changes others had done. When the developer committed his fix, the Build Master tried to build again. Lather, rinse, repeat.

When the Build Master finally got a build that compiled, he tried to install it. If it failed to install, we digged into it to find out why, fixed it and started over.

Sometimes it took until Friday afternoon before we had a build good enough for Quality Engineers to start testing. Needless to say, you could not commit anything during building or you could risk breaking the build.

This was a very stressful time! I really began to hate Thursdays.

When the next project started, I wanted the team to start building every night. People were generally against this saying it made no sense to build every night because the Quality Engineers could only test one build per week. Eventually I got permission to make an automated build script and make builds every night. (We agreed the Quality Engineers will test the Thursday build and pretend the other builds do not exist.)

It was much better! The nightly build revealed build problems earlier, every night really. The team no longer had to wait until Thursday afternoon to find out their source tree does not compile. Every morning the developers had email telling them if the build failed and it was pretty easy to see who should fix what. I was not stressed any more.

The Linux team has had automated nightly (well, daily, because we build at 4 pm) build from the start and we also do automated hourly builds.

An hourly build is even better than a daily build. You find out problems with your source every hour! This means you can fix them much sooner. And when you fix problems as early as possible, your daily build will be in much better shape. In fact, I don’t even remember the last time we had a broken daily build.

Why not take this even further? Why not build every 15 minutes? On every commit?

Currently we only build hourly because we test every hourly build. The hourly test is fairly comprehensive, it includes installation, basic functionality, some detection tests, even some WebUI tests and an uninstall at the end. All this testing takes some 40 minutes.

After Linux Security 7 is released, we plan to spread the test on multiple machines to make it faster. Hopefully we can then start building+testing every 15 minutes or less.

The holy grail of Continuous Integration would be to get immediate feedback when you do a bad commit. I’m not sure how we get to “immediate” but we keep on improving and that is what counts.

For a smallish team, communication and teamwork is usually smoothest when sitting in the same room. But, as the team grows, every person adds to the general noise and fuss levels in the room. People don’t just bring the noises they themselves make into the room. Every person also brings in more phone calls, visitors and spontaneous discussions.

We currently have 11 people sitting in the same room and I have to admit that at times our working environment is pretty hectic. We don’t get a lot of phone traffic, but it’s quite common to have a few conversations going on simultaneously accompanied by sound effects that state our latest hourly automatic test results. Luckily most of the team members are not easily disturbed, and don’t seem to be having concentration problems too frequently. The issue does come up at times though, and there has been one major “innovation” that has helped us a lot - Silent Hour.

Our daily scrum meeting is at 11.00 every day. After that there usually are some more discussions going on for a while, and then we go for lunch. Later, in the early afternoon, generally the most productive time of the day starts. To make sure it is used to the fullest, we have our Silent Hour (which actually lasts for 2 hours). We ourselves shut up (pair work with low-volume discussion is ok) and move any conversations to our IRC channel or out of the room, into the kitchen or a meeting room. A STOP sign on the door stops wannabe-visitors and asks them to lure whoever they want to talk to out of the room. Phones go silent as well.

We’ve had Silent Hours since last summer. At first we were afraid that our visitors might not appreciate it, but generally there have been no issues. Of course, every now and then someone just marches into the room to state their business and needs to be guided out, but surprisingly there have been no complaints over that. Actually, one co-worker thanked us for having the Silent Hour info on the door because it implicitly says that it’s OK to visit us outside the Silent Hour.

Sometimes we have forgotten to be silent ourselves. Still, the value of Silent Hour is verified by the fact that it hasn’t been forgotten for more than one day at a time.