We here at the F-Secure Linux team are currently working hard on our next major release, preliminarily scheduled for the fourth quarter of 2007. There’s going to be quite a few changes, and the whole feature set is not even completely decided yet. A lot of it depends on customer and partner feedback during the project as well as from previous versions, which is why we have decided to make a public Technology Preview at this relatively early stage. It should be noted that this is in early alpha stage - although we continuously test our builds and try to make sure it doesn’t crash and burn too badly, some of it contains very new code working deeply within your kernel, still wet behind its ears. In short: do not run it on a production machine under any circumstances. It can possibly crash your computer, and even (although unlikely) make it unable to boot without deep repair magic involved. I recommend using a virtualized environment (such as VMware) to try this out.

Despite these warnings, based on what we’ve heard from customers, I think this release has some eagerly-anticipated features.

Here’s a short summary of the things we’re bringing out:

• Our current sister products Linux Client Security and Linux Server Security will be merged into one product called F-Secure Linux Security. By using different keycodes, the user can choose what feature set to purchase.
• On the same theme, you will be able to entirely disable parts of the product that you do not need. For example, on a centrally managed installation where the end-user need not interact with the product, one can disable the web user-interface to conserve resources. If you already have an existing firewall management infrastructure in place, you can disable the firewall component. This has previously been done by many customers by simply removing the corresponding .config file in /etc/opt/f-secure/fsma/modules, but hopefully you can now do the same in a much cleaner and well-supported way.
• The installer will be simplified to not ask any questions upon installation. Instead, the customer can tweak needed settings using command-line tools, the web user-interface or the Policy Manager after installation. Of course, we will still support supplying the --auto command-line option to configure the product directly upon installation.
• We will provide better integration with the modern desktops with native alert notifications.
• Of course, under the hood there are tons of changes aimed at improving stability, usability and support for new technologies and platforms. One notable change is that we have decided to drop support for some old platforms like Red Hat Enterprise Linux 2.1 and SUSE Linux Enterprise Server 8, where maintaining compatibility would increase complexity regards to both product code base and testing efforts, with little added benefit. However, the final set of supported distributions is not decided yet - it will be decided as the project nears completion, after discussions with customers and partners.

To check out the Technology Preview, first read the release notes! Really, please do. It contains important information about known problems and the new installation and setup procedure. We haven’t got any manual ready yet, so the release notes is the closest thing you’ll get.

Then, download the package: f-secure-linux-security-7.00.6275.tgz (MD5, SHA1).

Please email us your feedback about the Technology Preview! You can find the address at the bottom of the page. If your feedback includes a bug report, please remember to mention which distribution (name and version) you’re using as well as kernel version.

Some of us were at the HP Linux Forum here in Helsinki last thursday and saw some nice presentations. The topics circled around the usage of Open Source Software in projects, JBoss, Red Hat, Xen virtualization, and Linux services offered by HP, quite naturally.

It was nice to hear that the discussion on Linux and Open Source isn’t anymore about if they are ready to do this and that, but rather how to take most out of them and how to migrate your existing systems into Open Source platforms.

We have just released version 5.52 of our Server Security (70 MB evaluation download) and Client Security (69 MB evaluation download). This release was mainly prompted by some issues discovered when running our product on Turbolinux, a popular Japanese Linux distribution and hence an important target platform for us. Also, in light of our recent security advisory FSC-2007-1, we would like to encourage all users to upgrade to the latest versions. Note that the latest version of F-Secure Internet Gatekeeper for Linux is affected: download the latest build here.

The 2nd Google Test Automation Conference will take place in New York on 23rd and 24th of August. I’ve been given the honor of presenting our team’s test automation system that’s in use for all F-Secure’s Linux/UNIX Anti-Virus products. The conference is free of charge, but the number of participants is limited to 150. If you’re working with testing or test automation you have a good change to see my presentation and many top speakers during the two days by applying to the conference here.

My presentation will introduce some ideas of test automation system architecture, using virtualization to test on ever increasing number of Linux variants, utilizing version control and moving to automated reporting and test documentation. I’ll be also covering some specifics of testing anti-virus products, testing proprietary products on open source platforms and testing products with GUIs, Web UIs, kernel modules and firewalls as well as HTTP/SMTP/POP proxies with clients and servers. And even bootable CDs. It’s quite clear that there isn’t a single free or commercial product that would do all that. So I’ll show how we have tackled many of these problems by modularity of the automation system and by keeping all the different parts easy to use and understand. And oh yes… I’ll be advocating “automating everything” :)

As mentioned by Alexey, currently the International Antivirus Testing Workshop is ongoing in Reykjavík, Iceland, and I am here representing the F-Secure Linux team. Here I am learning everything there is to know about malware testing, and, of course, enjoying the amazing nature of Iceland and the charming city of Reykjavík - yesterday we visited the Blue Lagoon geothermal spa.

Some of us has recently become addicted to Twitter. As I discovered that someone has already made a Net::Twitter Perl module, the natural extension of this lunacy was to integrate Twitter support into our LED sign. We created a common Twitter account, to which we added as friends all the team members that wished to participate. With just a few lines of Perl code, we then got our tweets prominently displayed on the team LED sign. Pure Web 2.0 goodness!

my $twit = Net::Twitter->new(username=>"foo", password=>"bar" );
my @seentweets;

sub fetchtwits() {

    my $timeline = $twit->friends_timeline();

    my $firsttime = @seentweets ? 0 : 1;

    return "" unless $timeline;
    TWEET: for (@{$timeline}) {
	my %tweet = %{$_};
	if ($firsttime) {
	    # if this is the first time we're running, just
	    # populate the seen list with all tweets so that
	    # we don't spew out the whole timeline on startup
	    push @seentweets, $tweet{'id'};
	}

	for (@seentweets) {
	    if ($_ eq $tweet{'id'}) {
		next TWEET;
	    }
	}
	my %user = %{$tweet{'user'}};
	my $msg = '<GD1>' . $user{'screen_name'} . ": " . $tweet{'text'};

	print "new tweet: " . $msg . " [" .$tweet{'id'} . "]\\n";
	toled('A', $msg);
	push @seentweets, $tweet{'id'};
	return $msg;
    }

    return "";

}

This weblog isn’t the first weblog started by Linux team. As mentioned in previous entry, our build system has had her own blog almost right from the start. Python is pretty popular programming language in our company and even though most of the build system is based on shell scripts and makefiles, there is a python script to send build announcements. Once when I had some extra time, I installed Wordpress to a virtual machine and found a python module for posting weblog entries. Then I added code to generate HTML versions of build announcements and post them to the weblog.

Now we have build history in easily navigated form. To find builds made on certain month or day, you can use monthly archives and calendar widget. There is also search box that lets you find builds based on any information contained in build announcements turned into blog entries. For example, you can enter bug tracking identifier to find out which build had fix for the bug or just enter build number to find out when build was made and what changes it has. Of course, there is also RSS feed.

Since build blog contains confidential information of products under development, it is strictly company internal blog.

Almost exacly one year ago, a day when I was working late here in our Helsinki headquarters, I suddenly took the subway downtown to Clas Ohlson, a store for “DIY products for house and home, technology and hobbies” as they present themselves. There I picked up a LED sign and promptly carried it back to the office. The only thing I knew about it was that it was “computer controllable” somehow - the product specs at the store didn’t say exactly how you could interface with it. Turns out it comes with a Windows program which you can use to program it, and the control commands are then sent over a serial wire to the sign. I didn’t quite know why I wanted it, but I had this feeling that it could be a really neat information radiator for our team. Of course, being a Linux team, we couldn’t depend on a Windows computer to run the display, so I started to observe how the Windows program worked. I configured my VMware virtual machine to redirect the serial I/O to a regular file, and then started the bundled Windows program and used it to send messages and watched the bytes come into the file instead of being sent through the wire to the LED sign. I could then attempt to change a couple of bytes and pass it on to the actual serial port and see what happened. When I entered the string “Text message entered” into the Windows application, what it sent down the serial wire was:

<ID00><L1><PA><FE><MA><WC><FE>Text message entered4B<E>

You eagle-eyed people have no doubt already spotted the last two characters appended to the string I wrote - 4B - and figured out that it’s a simple checksum of some sorts. So I went on sending some more messages to try to make some sense out of how that checksum was calculated.

The string “A” gave 35, while “AA” gave 74. “AAA” -> 35 again. Now we’re spotting a pattern. Around this time my colleague Juha had started peering over my shoulder and joined in on the thinking. He soon figured out that it was a simple XOR of the ASCII values of each character in the string, but with a starting value of 0×74. Later we would also learn the meaning of some, but not all, of the different command tags seen in the message packets too - for example, the device has several “memory pages” where you can store different messages in each page and then use a command to switch between pages. I wrote a small Perl script to construct the basic variant of these messages; something along this way:

sub toled {
    my $page = shift;
    my $str = shift;

    # calculate checksum
    my $checksum = 0x74;
    for (0..length($str)-1) {
        my $c = ord(substr($str,$_));
        $checksum = $checksum ^ $c;
    }
    # construct basic "display this on page $page" message
    my $ledcode = sprintf("<ID00><L1><P%s><FE><MA><WC><FE>%s%02X<E>",
                          uc($page), $str, $checksum);
    # send to serial device /dev/ttyS0
    open SERIAL, ">/dev/ttyS0";
    print SERIAL $ledcode;
    close SERIAL;
}

And suddenly I could control our gadget from Perl, which of course was awesome. This spawned a flurry of activity, and soon enough I had written a simple RSS parser that could feed titles from an RSS feed to the LED sign. We have an internal blog with announcements from our automatic build system, so I hooked my Perl script to our “build blog”’s RSS feed and voilà - the LED sign now served a useful purpose of always displaying the latest build information, including letting us now if any of the build had failed.

The next few days we scrambled to find a place to hang it where it would be visible not just to us but also to people walking by our team room, and a computer that could run it more or less permanently. We had an old 100 MHz Pentium II laptop that did an excellent job of running our little LED sign control script silently and surprisingly reliably, running a minimal Slackware installation. As an extra perk, we connected external loudspeakers to the laptop, and I modified the script to play a sound sample each time the word “failed” was mentioned by the LED sign. This results in a crashing sound being played whenever any of our continuous builds fail, immediately bringing it to the team’s attention.

Of course, I couldn’t stop there. I wanted to build generic interfaces so that the other people in the team could send their own messages the LED sign. I started out with an IRC interface - I made the script into a simplistic IRC bot that could receive commands from our internal IRC network. In the process, I also made it send all messages it displayed to its own IRC channel, so that people that didn’t have the sign in clear view could see the messages on IRC instead. Furthermore, I created a “drop directory” on an NFS server where people could drop files that would be read by the script and displayed. Now, one year later, quite many parts of our development and testing environment hooks into this little script: we get notification of tests currently in progress, test results, when builds are started and completed (or failed), test system load and so on.

In conclusion, while it may not be the end-all-be-all information radiator equipment - only being able to display some 250 characters per message being just one of many limiting factors here - this has anyway been one of the most fun applications of “information radiation” that I’ve seen. :-)

All of us have both desktops and laptops and we run VMware. Some of us have noticed that a laptop can be suspended and woken up with no ill effects to running virtual machines. Some of us see various problems in virtual machines after emerging from suspend.

VMware has in it’s Help menu a command called Tip of the day. One of the tips says:

On a laptop computer, suspend the virtual machine before you suspend or hibernate the host computer

VMware’s manual and Google have nothing else to add. Does anyone else have any further information on the problem?

Also, wouldn’t it be nice if VMware would automatically suspend running virtual machines when the host is suspended?

Today I was told that our main product Linux Server Security achieved the VB100 award, with “superb detection rates” and “a more professional feel than many, with some serious and thorough documentation”. That’s some warming words indeed. Sweet! Given the thorough scanning tests we put our products through every day (on tens of different Linux platforms), this is more of a reassuring confirmation that our testing is sound. Still, getting a neat little badge to display on the blog is always fun. :-)