Home / server / Questions / 34252
In Process
cjs
Asked: 2009-07-01 19:18:34 +0800 CST

Using a Patched libresolv and OpenSSH on Ubuntu

  • 772

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.

ubuntu package-management patch-management

2 Answers

  1. You want to do exactly as you suggest, and maintain patched packages. Setting up a repo is pretty straightforward, I just use apt-ftparchive to do the heavy lifting of writing out the Packages files. Have a procmail rule to watch ubuntu-security-announce list and warn you of any security updates for the packages of interest. If you've never built a package before you're in for some fun, but it's not particularly difficult if you're capable of reading documentation.

    • 1

  2. Set up an automatic repository on one of your internal servers, and sync up with ubuntu's version. Make sure none of your clients are adding the "proposed updates" repository from ubuntu, and register it yourself (as maintainer of the patch), that way you will be able to be ahead of the actual update and give your version in advanced.

    Name the version as a sub update, so it'll be "over" ubuntu's version, for example, current version is:

    $ apt-cache policy libc6
libc6:
  Installed: 2.9-4ubuntu6

    Assuming your organization is called example, it should be 2.9-4ubuntu6example1. You can even PGP sign your archives, for the extra security.

    There's no need to SSH, and you can use PackageKit + PolicyKit to let the users update it without giving them root access (assuming you're that strict).

    As a side note, I bet the reason that patch is not accepted is because of Ulrich Drepper, he rejects almost every patch from people "he doesn't trust". Soon, Debian will switch to eglibc, which has much more friendly developer who consider adding any patch.

    • 0