Wandering Thoughts archives


Why tiling window managers are not really for me (on the desktop)

For years now, the Unix geek thing to do has been to use a tiling window manager. There are a relative tone of them, and many of them promising the twin goals of simplicity and (full) keyboard control out of the box. However, I've never been particularly interested in any of them, despite my broad view that fvwm is a fairly complex window manager as these things go and definitely shows its age in some ways.

The short version of a large part of why I don't feel attracted to tiling window managers is that I generally like empty space on my desktop. Tiling window managers seem to generally be built around the idea that you want to fill everything up to make maximal use of your screen real estate. I don't feel this way; unless I'm going a lot, I actively want there to be empty space on my screen so that my overall environment feels uncluttered. If I only need one or two terminal windows active at the moment, I don't see any reason to have them take up the entire screen.

(Related to this is that I sometimes deliberately overlap windows in order to put certain windows in what I consider good or correct positions for what I'm doing without forcing others to shrink.)

I'm sure that at least some tiling window managers can be taught to leave empty space if you want it and not force the screen to be filled with windows all the time. And probably some can have overlapping, partially occluded windows as well. But it's not how people usually talk about using tiling window managers and so I've wound up feeling that it's not an entirely natural thing for them. I'd rather not try to force a new window manager to operate in a way that it's not really built for when I already have a perfectly good non-tiling window manager.

(There's also the issue of my use of spatial memory for finding windows, both active and especially inactive, which I also have the impression that tiling window managers are not so hot on.)

At the same time, I've seen tiling window layouts work very well in some circumstances when the layout is sufficiently smart; Rob Pike's Acme is the poster child for this for me. There are certainly situations where I would like to switch over to an Acme-style tiled approach to window layout (probably usually when my screen gets busy and cluttered with active windows). It's just that I don't want to live in that world all of the time (and, to be honest, there are issues with xterm that make it annoying to keep changing its width all the time).

It's a pity, though. Some of those tiling window managers definitely do look cool and sound interesting.

PS: All of this is relatively specific to my desktop, where I have a physically large display and so it's frequently uncluttered, with room to spare.

(I'm not particularly attracted by 'control everything from the keyboard', either. I like using the mouse for things it's good at.)

unix/TilingWMNotReallyForMe written at 20:38:42; Add Comment

Spam and virus filtering on email is a risk (although likely not a big one)

If you have a decent-sized email system, you're probably running incoming email through some sort of anti-virus and anti-spam system. It may be a commercial product such as the one we use, or it may be a free one such as SpamAssassin or ClamAV. There are ways around needing such a system while still allowing a reasonable amount of incoming email, but they let some spam through and they require aggressively blocking attachments in order to try to exclude viruses.

These systems, commercial or free, are a potential security risk. We know that desktop anti-virus scanners have vulnerabilities (both in the engines and in things like their update mechanisms), so it's only prudent to assume that server-based systems do as well, especially for anti-virus systems. Modern AV systems are trying to parse and understand complicated file formats, almost certainly using code written in C and not aggressively hardened; it would be a miracle if they didn't have exploitable vulnerabilities somewhere.

(At least one commercial system definitely had vulnerabilities, although they may or may not have been exploitable.)

At one level, this is really quite alarming; your email AV system is completely exposed to inbound email from the outside world, since automatically checking that email is its entire job. An attacker who knows and can exploit a vulnerability in it can send you a malicious message and your system will be owned without any action on your part. It's not too much different from your web server having a remotely exploitable vulnerability. Yes, it's likely that coming up with a reliable attack against your AV system will be harder, but it's very likely it can still be done.

So should you abandon use of an AV system, and in fact of all content-scanning systems that look at your inbound email? As usual, this is a balance of risks question. In particular I think it's a question of how easily AV systems can be exploited generically and have something useful done with them.

The reality of life is that if an attacker is targeting you specifically, they're probably going to get in somehow. It's worth making sure that your AV system is not exceptionally vulnerable, but at the same time it is probably not the sole weak point in your environment, and not having an AV system or other content filtering has its own set of risks. For most sites, you are probably better off overall having an email AV system even if it provides an additional attack point for someone who is targeting you specifically.

But specific attackers aren't the only attackers we have to worry about; there are also mass attackers, people who find some broadly spread vulnerability and attack everyone they can find with it in order to do various sorts of nastiness (sending out spam, holding your files to ransom, selling access to other people, whatever). If a mass attack is possible at all, it is really the biggest risk, simply because mass attackers spray their attack widely in order to reach as many targets as possible.

(As a corollary, there probably will never be a mass attack against your custom local filtering, although there may be a mass attack against some common sub-component you're using in it, such as a MIME parsing library or a compression library.)

I'm wary of saying that there can't be a successful mass attack against an email AV or anti-spam scanner, but I think that the odds are against it. These systems are deployed on varied systems, in very varied environments, often in varied versions of the software itself, and there are a fair number of different software packages that mail systems use. Barring a glaring, trivial vulnerability, a would be mass attacker probably can't develop a truly broad single exploit even for a broadly spread vulnerability; they might need a different one for different Linux releases, for example. Then they'd have to find enough mail systems on the Internet that were running the specific AV/anti-spam system on Debian X or CentOS Y in order to make a mass attack worth it. It just seems unlikely to me.

(Things like web servers are more exposed to mass attacks because they are easier to mass scan and assess.)

spam/SpamAndVirusFilteringRisk written at 01:25:39; Add Comment

Page tools: See As Normal.
Login: Password:
Atom Syndication: Recent Pages, Recent Comments.

This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.