cjs's questions

I've got an AMD Athlon XP-2500+ host (Shuttle MN31 motherboard, nForce 2 IGP + MCP-T chipset) running 32-bit Ubuntu 9.10 (i686 2.6.31-20-generic kernel). Unfortunately, it appears that the clock drift on it is so bad (it advances close to an extra second every minute) that ntpd can't keep the machine in sync.

How do I deal with this so I can get ntpd working?

I keep most of my home directory's dot files under revision control, so that I can easily move changes between any of the five or so desktop machines and dozens of servers that I use. Unfortunately, my ~/.gconf directory is a bit of a pain when it comes to this, because gconfd seems to really like making arbitrary whitespace changes and, worse yet, updating the mtime="..." attributes on entries that it hasn't changed.

Has anybody any thoughts on good ways to deal with this? I would prefer never to have to commit whitespace changes or time changes when a value hasn't changed, so that I can easily track my diffs over time.

I have an entry from an OpenSSH known_hosts file; I'd like to generate an SSHFP resource record for this. I can use ssh-keygen to generate the fingerprint with no difficulty:

$ ssh-keygen -f foo_known_host -l
1040 09:a0:5c:5f:43:fb:e5:25:d8:0c:d8:dc:d7:7a:c4:62 foo.example.com. (RSA)

But it doesn't seem to like it for a DNS fingerprint record:

$  ssh-keygen -f foo_known_host -r foo
failed to read v2 public key from foo_known_host.

So how do I do this?

Note: If you came here via asking a search engine how to generate an SSHFP record from a remote host (not a local copy of the fingerprint as above), that's done via ssh-keyscan -D machine.name –.

I'm setting up some new Ubuntu servers, and I'd like to secure the data on them against theft. The threat model is attackers desiring the hardware or rather naïve attackers desiring the data.

Please take note of this section.

The threat model does not include smart attackers desiring the data; I presume they will do one or more of the following:

1. Splice a UPS into power cable in order to keep the machine running continuously.

2. Insert a pair of Ethernet bridges between the computer and the network termination point that will bridge the traffic over a wireless network of sufficient range that the host will maintain network connectivity.

3. Open the box and use a probe on the memory bus to grab interesting stuff.

4. Use TEMPEST devices to probe what the host is doing.

5. Use legal means (such as a court order) to force me to disclose the data

6. Etc. Etc.

So what I want is to have some, or ideally all, of the data on the disk on an encrypted partition, with the key material necessary to access it on external media of some sort. Two methods I can think of for storing the key material are:

1. Store it on a remote host accessible via the network, and configure enough of the network to retrieve it during the boot process. Retrieval would be allowed only to the IP address assigned to the secured host (thus not allowing access to the encrypted data if it were booted on another network connection) and could be disabled by administrators if the machine were discovered to be stolen.

2. Store it on a USB storage device that is made in some way significantly more difficult to steal than the host itself. Locating it remote from the host, such as at the end of a five meter USB cable leading off into another corner of the room, or even another room, would probably significantly decrease the chances of attackers taking it. Securing it in some way, such as by chaining it to something immobile, or even putting it into a safe, would work even better.

So what are my options for setting this up? As I said before, I'd prefer to have everything (aside from perhaps a small boot partition that does not contain /etc) encrypted, so that I don't have to worry about where I'm putting files, or where they're accidentally landing.

We're running Ubuntu 9.04, if it makes any difference.

We've got a couple of dozen Ubuntu systems (ranging from 8.04 to 9.40, both desktops and servers with only serial console access on which we'd like to run a patched version of glibc.

In particular, this is to fix the inability of glibc's resolver to allow programs such as the ssh client from OpenSSH to set the AD bit; the general gist of what we'd like to do is available at the blog post How to get OpenSSH to see DNSSEC AD flags on SSHFP lookups with glibc. We're contemplating doing a slightly more more extensive modification, adding AD bit support to the header file so that we can compile a standard ssh binary, though that would involve replacing the ssh client as well.

So my question is, what's the easiest way to make the change, maintain it in sync with regular updates from Ubuntu, and distribute it to all of our machines?

I'm guessing that the optimum thing might be to maintain our own copy of the Ubuntu source packages, updating ours with every update, building new versions as appropriate, and distributing them by setting up a server that goes in the list of package servers for each machine. But I don't know enough of the details of how to do this to know if this is the best option. If it is, I'd like some pointers to the details of setting this up.

Some will probably be wondering why I would like to do this. There are two reasons:

1. This feature is not going to be added to glibc any time soon. It's been missing for more than five years now, and nobody is showing any concern about it; rather, they're saying they feel that adding the feature is too dangerous due to the "high security impact" of the change, or some such thing.

2. We have a strict policy that you may not connect via ssh to company machines whose keys are not verified (i.e., we use the "StrictHostKeyChecking yes" ssh option).

I'd like to avoid any discussion of either of the above points here. If you want to find out more about the glibc maintainers' policy, or if you don't understand the attacks to which you are opening yourself when you don't follow our security policy, post a separate question, e-mail me with its URL of it, and I will link to it from here.

One of the basic principles of computer security is never to run anything you don't need.

I was pgrepping for a process today when I noticed that my Ubuntu 9.04 (desktop) machine was running a git server daemon. After a quick swear, I discovered that the git-daemon-run package had been (probably inadvertently) installed, and removing it got rid of that process (and ensured that it wouldn't be restarted later).

But in other cases, I want the server package to be installed, but don't want the server daemon running. For example, I use lighttpd for internal testing (it's started by specific test scripts for some applications, and listens only on localhost in those configurations) but I don't want it listening for outside connections with some random config file. (If I wanted to run one listening for outside connections, I'd configure and run it myself.)

I really don't like running all sorts of random servers I don't need on Internet-exposed machines, since who knows what security holes they open up. And I prefer not to have to muck about with firewalls, since that's yet another potential source of errors and misconfigurations that can open up security holes. It's not so hard to have Unix machines configured not to start any servers unless specifically asked to do so by the admin; NetBSD (and OpenBSD, too, I think) come this way by default.

How do I configure my Ubuntu systems never to start any kind of server daemon unless I specifically tell it I want it started?

(Asking to have a package installed is not, in my book, asking to start a server. If it is supposed to be, it's a terrible user interface, since many package installs don't even have a server to start, so it makes it far too easy to inadvertently start a server without realizing you've done so.)

EDIT: Just to make it clear, the problem is not that I want to be able to stop existing servers. The problem is that I don't want new servers started without an explicit request. This means I should be able to do any sysadmin task, such as installing a package, and be confident that no servers have started. Most responses do not address this point.

I've recently acquired a SuperMicro X8DTU-F motherboard, which has a built-in BMC, which basically runs the IPMI system. It turns out to be a small Linux system running on an ARM processor.

Unfortunately, it's running a boatload of software, much of which I don't need, and I don't have the ability to put it behind a firewall. However, I do want the IPMI functionality. Does anybody who has used one of these have some specific suggestions on how to secure the thing? It boots from what is essentially a ROM filesystem, and there don't even seem to be any hooks to turn off any of the various servers it runs....

I'd also be interested in how I might verify the list of names and passwords that can be used to access the system through all of the various services. The default is ADMIN / ADMIN, but none of the files in /conf or /etc have 'ADMIN' in them, which rather worries me. There are /conf/shadow and /conf/webshadow files, with mysterious 'test' IDs in them, which doesn't make me feel particularly comfortable either.