Check then use is a dangerous security pattern
A commentator here recently noted the danger ofthe Unix pattern of stat()'ing a filename, checking to see if the statresults look good, and then open()'ing the file. The problem is thatin many cases an attacker can change what the filename is pointing tobetween the time you stat() it and when you open() it, so that youcheck a harmless thing but open a dangerous thing.
In thinking about this, I came to realize that this is an example
Doing one-shot booting with GRUB
For a long time, one of the advantages of LILO over GRUB was that LILO had a one-shot mode, where it would make an entry thedefault for only one reboot. I've been pleased to recently discover thatGRUB can now do this too, although in the grand Linux tradition it's nottoo documented.
The magic incantation is the GRUB shell command:
savedefault --default=--once (This has to be issued in a GRUB shell, such as what you
Implicit generalized open()'s are dangerous
A number of languages have
open()functions that are generalized bydefault; they open more than plain files, sometimes far more. Suchfunctions are dangerous bear traps lying in wait for the unwary andinsufficiently paranoid, because what the programmer thinks is a simplefile open may be something very different and more dangerous. Inturn, this means that all an attacker needs to do is find some way to supply a 'file name' that your programwill try to open.There's two core problems: the
A more abstract view of the generalized open() issue
Part of the generalized
open()problem is thatsuch generalizedopen()s silently cross what I will call 'securitycontexts'. Here a security context is both what you can do and wherethe data is coming from; read versus write versus run a pipe, localfiles versus remote URLs, and so on.When something is security sensitive (and
open()is here), it shouldeither be explicit about what security context it is operating in,or it should at least be explicit about the
A surprise about Linux serial consoles
Here is a surprise I just discovered about magic SysRq and serialconsoles: in order to have a serial console respond to magicSysRq, you need something talking to it. If your serial console is
/dev/console, I believe that this is automatic; however, if it isnot (if you have hooked it up to debug systemlockups in X, for example, as a not entirely hypothetical example), youneed to run agettyor something on the serial port in order to havethe kernel notice
I don't like smooth scrolling
Courtesy of upgrading my home machine to Fedora 8 and getting a new versionof liferea in the bargain, I have been remindedof something: I really don't like applications that do smooth scrolling.
While I could pick specific nits, I suspect that a good part of thiscomes down to metaphor choices; I tend to think of scrolling as a 'turnthe page' action, for which the closest computer equivalent is justimmediately replacing the text with no fancy effects (although I want aline or two of
A depressing thing about phish spam
For a while, my general reaction to receiving phish spam from somewhereis to block it from sending me further email. This habit has led to mediscovering something depressing: how many of those places later tryto send me more email, often months after the first incident.
This is depressing because phish spam is usually sent from compromisedmachines. Getting more mail from the same machine is a bad sign; itmeans that the machine has almost certainly not been cleaned up, and isinstead still compromised and being used for
Using Linux's magic SysRq feature
The 'magic SysRq' is a feature of the Linux kernel where you candirectly invoke certain kernel commands, regardless of what happens tobe going on at user level and often even if the system is fairly brokenotherwise. Commands are conventionally described by the key that's usedto invoke them.
There are three ways of invoking magic SysRq commands:
- writing the command key to
/proc/sysrq-trigger, for examplewith 'echo>/proc/sysrq-trigger ' in a root shell
Why large ISPs like SPF (the cynical view)
One of the peculiarities of SPF and related schemesis that many large ISPs are quite enthusiastic about it, especiallyfree webmail places like Hotmail, Yahoo, and Google Mail. However, thisenthusiasm rarely extends to blocking incoming email that fails SPFchecks, although they are happy to encourage you to use SPF on yourown mail.
The cynical view of this is that ISPs love the idea of SPF because itgives them more control over their customers. With SPF, their customersare not only tied to the ISP for reading
Safely updating files that are read over NFS
To elaborate on an old entry a bit, let'ssuppose that you have important system data files that you expose to allof your machines via NFS, and that you need to re-generate and updatethem every so often.
When you regenerate files locally, you need to make sure that there'salways a version of the file present, and that the file's alwayscomplete. When you add NFS there's a third, subtle requirement: youcannot immediately remove the old version because a
Menu