Suppose that you want to use a non-standard shell as your login shell(for the purposes of this, 'non-standard' means that it's not installedsystem-wide; you have to compile your own version). Further suppose,for the sake of argument, that the shell you want to use doesn't havea command-line option to tell it to be a login shell.

If your shell did have such a command line option, using it as yourlogin shell would be

There are a reasonable number of good things about bash (and thegeneral GNU program attitude of which it is a standards-bearer). But every so often it does something that causes meto grind my teeth. This time around the irritation is what bash hasdone to the innocent exec command.

What they've done is simple: they've made exec take options.

The easiest way to explain the problem with this is in illustratedform. So:

sh$ exec -rc
<... program

The first principle of analyzing compromised machines is simple:

You can't trust anything running on a compromised machine.

If you are sufficiently paranoid, everything on a compromised machinemight be compromised and lying to you: the programs, the sharedlibraries, the data files, even the kernel. You cannot trust any ofit. This means that you cannot use a compromised machine to examineitself . Not even a little bit, however convenient it would be.

(The partial exception is that if a test on the compromised

Given the problems that prelinking adds to verifying that two systemsare identical, you might sensibly ask how RPM verification deals with this problem. Unfortunately, the answer isnot calculated to make security people happy.

RPM has no native knowledge of how to analyze prelinked things; insteadit delegates this work to an external program. When RPM detects that itis trying to verify a prelinked file, it starts the program and expectsit to produce the original, un-prelinked version of the file on standardoutput. RPM then verifies

Here is something that is perhaps obvious, but still worth mentioning:all anti-spam work is in a sense pure overhead, in that it is time andresources spent fixing a situation to return it to the way it was beforethe spammers showed up. Anti-spam work does not actually improve emailin a broad sense, it just makes it as not-bad as possible.

(It is possible that anti-spam work will lead to techniques thatimprove email overall, perhaps better ways of automatically sorting and

There reaches a certain point in the life of many projects, especiallyopen source projects, when your bug reporting system just doesn't workany more. By 'doesn't work' I don't mean that your systems fall overand the software stops working; I mean that the system stops doing anygood and instead becomes the place where bug reports go to die. (Actualimportant bugs get reported and often tracked by different channels.)

So how can you tell if you've reached this point

Courtesy of Don Kaminsky's slides for his Black Hat DNS talk, I wound up reading Attacks on PackageManagers ,which identifies a number of attacks that can be mounted if you canset yourself up as a package repository mirror for your favoriteLinux distribution. A number of the attacks are straightforward,but judging from the Slashdot discussion the dangers of unsignedrepository metadata are not as clear. So here is an attempt toexplain them simply.

Suppose that you are an attacker with a repository mirror (the papershows that

One of the little challenges with writing Unix programs in Python isthe search path problem. The natural structure of Python programs is tosplit functionality up into a bunch of modules and then import themall in the main program, but the natural structure of a Unix program isto put its binary into one directory (such as /usr/bin ) but all ofits helper bits into a second, completely different directory. So theproblem is: how is a Unix Python program supposed to find its modules?

(The

There is a certain view, one that is easy for people to fall into,to the effect that while backwards compatibility in new versions oflanguages is important and should be given due weight, sometimes thelanguage designers can, do, and should decide that the change isimportant enough so that it should be made. Let us call this thelanguage designer view of language changes.

The problem for this view and for the decisions that come from itis simple:

Programmers do not have to accept what you give them.