Louwrentius

Systemd is a more modern replacement of sysvinit and its in the process of being integrated into most mainstream Linux distributions. I'm a bit troubled by one of it's features.

I'd like to discuss the Forward Secure Sealing (FSS) feature for log files that is part of systemd. FSS cryptographically signs the local system logs, so you can check if log files have been altered. This should make it more difficult for an attacker to hide his or her tracks.

Regarding log files, an attacker can do two things:

1. delete them
2. alter them (remove / change incriminating lines)

The FSS feature does not prevent any of these risks. But it does help you detect that there is something fishy going on if you would verify the signatures regularly. So basically FSS acts a bit like Tripwire.

FSS can only tell you wether or not a log file has been changed. It cannot tell you anything else. More specifically, it cannot tell you the reason why. So I wonder how valuable this feature is.

There is also something else. Signing (sealing) a log file is done every 15 minutes by default. This gives an attacker ample time to alter or delete the most recent log events, often exactly those events that need to be altered/deleted. Even lowering this number to 10 seconds would allow an attacker to delete (some) initial activities using automation. So how useful is this?

What may help in determining what happened to a system is the unaltered log contents themselves. What FSS cannot do by principle is protect the actual contents of the log file. If you want to preserve log events the only secure option is to send them to an external log host (assumed not accessible by an attacker).

However, to my surprise, FSS is presented as an alternative to external logging. Quote from Lennart Poettering:

Traditionally this problem has been dealt with by having an external secured log server 
to instantly log to, or even a local line printer directly connected to the log system. 
But these solutions are more complex to set up, require external infrastructure and have 
certain scalability problems. With FSS we now have a simple alternative that works without 
any external infrastructure.

This quote is quite troubling because it fails to acknowledge one of the raison d'être of external log hosts. It seems to suggest that FSS provides an alternative for external logging, where in fact it does not and cannot do so on principle. It can never address the fact that an attacker can alter or delete logs, whereas external logging can mitigate this risk.

It seems to me that systemd now also wants to play the role as some crude intrusion detection system. It feels a bit like scope creep to me.

Personally I just wonder what more useful features could have been implemented instead of allowing you to transfer a log file verification key using a QR code to your smartphone (What the hell?).

This whole observation is not original, in the comments of the systemd author's blogpost, the same argument is made by Andrew Wyatt (two years earlier). The response from the systemd author was to block him. (see the comments of Lennart Poettering's blogpost I linked to earlier).

Update: Andrew Wyatt behaved a bit immature towards Lennart Poettering at first so I understand some resentment from his side, but Andrews criticism was valid and never addressed by him.

If the systemd author would just have implemented sending log events to an external log server, that would have been way more useful security-wise, I think. Until then, this may do...

TL;DR Yes it works with some modifications of the driver source.

A USB Wi-Fi adapter I used with a Raspberry Pi broke as I dropped it on the floor, so I had to replace it. I just went to a local shop and bought the Sitecom AC600 adapter as that's what they had available (with support for 5Ghz networking).

I had some hope that I would just plug it in and it would 'just work™'. But no. Linux. In the end, the device cost me 30 euro's including taxes, but the time spend to get it to work may have made this a very expensive USB Wi-Fi dongle. And it's funny to think about the fact that the Wi-Fi dongle is almost the same price as the Raspberry Pi board itself.

But I did get it working and I'd like to show you how.

It started with a google for 'sitecom ac600 linux' which landed me on this page. This page told me the device uses a MediaTek chipset (MT7610U).

So you need to download the driver from MediaTek. Here is a direct link

So you may do something like this:

cd /usr/src
wget http://s3.amazonaws.com/mtk.cfs/Downloads/linux/mt7610u_wifi_sta_v3002_dpo_20130916.tar.bz2
tar xjf mt7610u_wifi_sta_v3002_dpo_20130916.tar.bz2
cd mt7610u_wifi_sta_v3002_dpo_20130916

Now you would hope that it's just like this:

make
make install

And we're happy right? Linux FTW! Well, NO! We're using Linux so we have to work for stuff that works right out of the box on Windows and Mac OS.

So we first start with editing "include/os/rt_linux.h" and go to line ~279. There we make sure that we edit the struct like this:

    typedef struct _OS_FS_INFO_
 {
    kuid_t              fsuid;
    kgid_t              fsgid;
    mm_segment_t    fs;
 } OS_FS_INFO;

Basically, the words int are replaced by kuid_t and kgid_t, or else, compilation will abort with an error.

Ofcourse, the Sitecom AC600 has an USB identifier that is unknown to the driver, so after compilation, it still doesn't work.

lsusb output:

Bus 001 Device 004: ID 0df6:0075 Sitecom Europe B.V.

So google landed me on this nice thread by 'praseodym' that explained the remaining steps. I stole the info below from this thread.

So while we are in the source directory of the module, we are going to edit "common/rtusb_dev_id.c" and add

{USB_DEVICE(0x0DF6,0x0075)}, /* MT7610U */

So this will make the AC600 gets recognised by the driver. Now we also need to edit "os/linux/confik.mk" and change these lines like this:

HAS_WPA_SUPPLICANT=y
HAS_NATIVE_WPA_SUPPLICANT_SUPPORT=y

So no, we are still not ready yet. I'm not 100 percent sure that this is required anymore, but I found this nice thread in Italian and a very small comment by 'shoe rat' tucked away at the end that may make the difference between a working device or not.

We need to edit the file "os/linux/config.mk" and go to line ~663. Then, around that line, change

CHIPSET_DAT = 2860

to:

CHIPSET_DAT = 2870

Yes. Finally! Now you can do:

make
make install

Imagine that such a 'make' takes about 20 minutes on a Raspbery Pi. No joke.

Now you can either do this:

modprobe mt7650u_sta

You should see something like this:

root@raspberrypi:/usr/src# lsmod
Module                  Size  Used by
snd_bcm2835            16181  0 
snd_pcm                63684  1 snd_bcm2835
snd_page_alloc          3604  1 snd_pcm
snd_seq                43926  0 
snd_seq_device          4981  1 snd_seq
snd_timer              15936  2 snd_pcm,snd_seq
snd                    44915  5 snd_bcm2835,snd_timer,snd_pcm,snd_seq,snd_seq_device
soundcore               4827  1 snd
mt7650u_sta           895786  1 
pl2303                  7951  0 
usbserial              19536  1 pl2303

You should be able to see a 'ra0' device when entering ifconfig -a or iwconfig and just configure it like any wireless device (out-of-scope).

So once up-and-running, the Sitecom AC600 works fine under Linux and even sees and connects to 5 GHz networks. But not without a caveat of-course. I needed to configure a 5 GHz channel below 100 (I chose 48) on my Apple Airport Extreme, or the Wi-Fi dongle would not see the 5GHz network and would not be able to connect to it.

So I hope somebody else is helped by this information.