Eugeni's blog

One of the most asked features for msec was to provide a “summary” screen, which could show the current state of system security to the user without making him go through all the possible security options and system tools.

Since today, this features was added to msecgui, showing the summary for three of the most important parts of system security: the firewall status, security overview and status of system updates.

Summary screen for msec

Of course, we all know that it is cooker version, and it is by no means final point on the UI design and functionalities . And, as usual, comments are more than welcome!

As promised in one of the past blog posts, a few more news about msec.

Since 2009.1, msec was supporting an arbitrary number of custom security levels, providing two levels by default: standard, focused on casual desktops, and secure, focused on security-concerned machines. Clearly, this was not covering all the possible use cases, and, while it was possible to create custom security levels for different users needs, few users actually dared to do so.

Starting with 2010.1, msec will provide a larger number of custom, task-oriented security levels. Among such levels, initially are the netbook (focused on low-end machines, running mostly on batteries, with a single local user and no remote accesses); fileserver (focused on a network server, such as SAMBA, NFS, or a database server, where only authenticated users are allowed), and webserver (focused on a web-facing server, attending unauthenticated and unknown users). The idea is to allow users to focus on their specific tasks (e.g., creating a web server, or configuring the netbook), without going too deep into the configuration options.

The msecgui UI was also improved to support those levels, among with user-created custom levels:

Msec levels selection, including the provided levels among with user-created ones

Besides those changes, the UI was simplified a bit thanks to a great cooker discussion and comments from Fabrice Facorat (and will be further improved in newer versions), the support for configuring the log retention period was introduced, and a few bugs were fixed.

More changes are still to be implemented in msec, but I thought that the ones I described in this post are interesting enough to deserve a new msec release.

Stay tuned for future updates!

I just noticed this days that, according to smartctl, the hard disk on my notebook has reached 365 days on Power_On_Hours variable. As the notebook itself has almost 2 years of age (I bought it in March of 2008), it is almost a double birthday-combo .

However, at this age, it is obvious that the hard disk of the notebook was not prepared to endure such challenges nicely. Both of its speed (5400 RPMs), durability, capacity, and so on were targeted on a more light use.

On the other hand, the system has 3GB of RAM, which is more than enough for most of my tasks. So after some thinking, I’ve been using some small script to automatically improve the system performance by offloading the most I/O-consuming stuff to RAM for the past few months.

How does it works? Simple. I have a small script which grabs content of a disk directory which I expect to receive heavy use (for example, /usr/lib/firefox, or the rpm BUILD/ directories which receive lots of I/O when building packages, and so on), and converts them into a RAM disk. This way, when anything inside such directory is accessed, it requires absolutely no hard disk I/O, the seek times are non-existent as well, and the throughput is incredible.

For example, if I build mozilla-thunderbird by using real hard disk BUILD directory, it takes almost 2 hours to build. If I use ramdisk for just the BUILD directory, the time required for such task drops down to about 30 minutes. The firefox startup time (both cold and hot – e.g., the first execution and consecutive ones) have the same time of about 1 second; and so on.

So, without further words, this is the script I am using:

#!/bin/bash
#
# This script remounts a directory in tmpfs (ramdisk) to speed it up
#

DIR=$1
SIZE=$2

if [ ! "$UID" = "0" ]; then
    # this script must run by root. Let's try sudo'ing to root..
    exec sudo $0 $*
fi

if [ ! -d $DIR ]; then
    echo "Usage: $0 <full path to a directory>"
    exit 1
fi

if [ "a$SIZE" = "a" ]; then
    OPTIONS=""
else
    OPTIONS="-o size=$SIZE"
fi

# first, copy everything somewhere to reuse it later
TMP=`mktemp`
tar cpf $TMP $DIR

# remount dir as ramdisk
mount -t tmpfs $OPTIONS $DIR $DIR

# unpack everything back
(cd / && tar xpf $TMP)
rm -f $TMP

To use it, just save it under a name like toram and use it on the directory you want to move to ramdisk. The second optional parameter is the size of the ramdisk to use – as by default tmpfs mounts itself with 50% of available ram, sometimes you may want to use more or less memory.

Just some examples on how to use it:

# toram `pwd`/BUILD (will remount current BUILD directory in RAM)
# toram /usr/lib/firefox-3.6 (will remount firefox directory in ram)

I hope this could be useful to someone .

It has been quite some time since I last posted here about msec. For the past few weeks, it received some attention and now I guess many of the features I wanted to push for Mandriva 2010.1 are implemented. So I’ll describe the most interesting ones in this blog post (and save some for later ).

First of all, starting with Mandriva 2010.1, msec will support user-defined periodicity for all periodic security checks. Therefore, it is possible to specify if each test should be executed daily (like in all previous msec versions), weekly or even monthly. In my opinion, this feature is one of the most interesting among all others, because it allows you to fine-tune the balance between security checks and daily I/O load caused by some expensive checks.

By default, checks which require lots of I/O (e.g., checking for unowned files, or world-writable files, and so on) will run weekly on the standard security level. Why so? Because this check was responsible for approximately 80% of all time required to run the periodic checks, and on most of the machines its results did not differ between consecutive days. Surely, it is nice to have a daily notification of all those changes, but the I/O cost of it is unacceptable high. Of course, you can define the periodicity of all such checks to be daily when you want, by using msecgui application of editing the configuration file manually .

Another interesting feature was the de-duplication of variables between main msec configuration file (security.conf) and the level configuration file (for example, level.standard). On previous versions, all variables were defined in security.conf, even if they have exactly the same value as the default one for the current security level. This way, it was easier to see all the configuration at once by looking into /etc/security/msec/security.conf file. On the other hand, it lead to duplication of almost all variables..

So for 2010.1, the behavior when saving the configuration file was modified to be more logical (and similar to the one of msecgui, which displays variables that differ from the default values for the security level in different way). If you want to redefine a variable, just specify it in security.conf and this change will take effect. If you want to disable a variable completely, just define it to an empty value (like, CHECK_SOMETHING=), like in previous versions, and it will be disabled.

To simplify this, we could use the following analogy: in previous msec versions (e.g., 2009.1 and 2010.0), the security.conf file contains the whole security configuration of msec plus the name of the security level which is used as base. In 2010.1, it contains the reference to the base security level plus only the variables which must be overridden for this level. In other words, on Mandriva 2010.1 just by looking at the msec security file it is possible to say “this machine is configured to use the same configuration as on standard security level, except those three checks that should be disabled).

There is yet another reason for this change, which will be described in details when it gets implemented (probably in a few coming weeks). So stay tuned for more news .

Another feature was the possibility of running the RedHat sectool checks periodically, among with all other msec checks. Just install sectool package from the contrib, and its checks will be executed automatically by msec.

Additionally, the integration between msec and msecperms applications was improved, making it easier to switch security levels and creating custom levels.

Besides those changes, several msec messages were improved to make them easier to understand by non-geek users , and, like usual, several bugs were fixed.

Like always, I am very interested in your feedback on those changed. Please, feel free to drop me a note whether you like these features, dislike them, or any other kind of comments about msec.