If I made one of those work-site signs that tracked “Days since last incident”, and made one for “Days since last in-the-wild remote-root worm” for Windows and Linux, what would they each say? 0 and 7304 respectively?
Update: while the post was tongue-in-cheek (everyone suffers when any large subset of computers is being attacked), I should lower the Linux days count to 2783 (for L10n on March 23, 2001, which is slightly newer than Ramen on January 17, 2001). Thanks for everyone’s comments. :)
SSH’s new “VisualHostKey” option (in Ubuntu Intrepid and Debian Lenny) is great fun. Normally it is disabled, but it seems that “ssh-keygen” turns it on when generating new keys. In celebration of the Ubuntu release, here is a script to entertain yourself with RSA ASCII-art, care of SSH and your system’s entropy pool:
#!/bin/sh
set -e
DIR=$(mktemp -t -d rsa-art-XXXXXX)
trap "rm -f $DIR/key*; rmdir $DIR" EXIT HUP INT QUIT TERM
while :
do
ART=$(ssh-keygen -t rsa -f $DIR/key -N "" | tail -n 11)
rm -f $DIR/key
/bin/echo -e "\x1Bc"
echo "$ART"
done
Makes me feel like I’m watching Life. (Use control-C to stop it.)
Feisty is now officially at end-of-life.
Looking back through my build logs, I can see that my desktop spent 34 hours, 44 minutes, and 46 seconds building 255 security updates. (And 25 hours, 40 minutes, 13 seconds doing 249 builds during the Feisty devel window.) As before, these times obviously don’t include patch hunting/development, failed builds, testing, stuff done on my laptop or the porting machines, etc.
As a correction to the Edgy EOL post, my desktop actually spent 50:59:40 doing 322 security builds and 04:14:23 doing 84 devel builds.
Current standings:
dapper: 49:42:36
gutsy: 43:14:36
hardy: 166:11:15
intrepid: 70:24:52
As mentioned, these numbers are mixed devel/security times.
Thank you Feisty! You were much more stable than Edgy, even if we didn’t see eye-to-eye about wifi connectivity.
Major props to NCommander for taking on the painful experiment of getting the entire Ubuntu Intrepid archive rebuilt with PIE on amd64. After getting all the other hardening defaults enabled for Intrepid, PIE is the last on the original list for enabling “by default”. Due to the overhead of PIE on i386, it’s really only an option on architectures with lots of general registers.
Here are my notes on growing a KVM disk image’s root filesystem. I had a few 4G partitions that really needed to be bigger. This shows how to get a report on the sizes of the disk images, convert them to raw, work on the partition tables, grow the root filesystem, and rebuild the swap partition with the original UUID. With some work, it could probably become fully scripted, but since the partition layout may not always be the same from VM to VM, the “fdisk” step needs human interaction to delete and rebuild the partition table. Note that the method below also maintains the sparseness of the images.
# Look for files to change
for i in /vmware/*/*{vmdk,qcow2}; do qemu-img info $i; done
...
# Pick one...
cd dir...
ORIG=64bit-Ubuntu-7.10-desktop.vmdk
SIZE=8G
ORIG_TYPE=$(echo $ORIG | awk -F. '{print $NF}')
TARGET_TYPE="qcow2"
TARGET_BASE=$(basename "$ORIG" ."$ORIG_TYPE")
TARGET_RAW="$TARGET_BASE".raw
TARGET="$TARGET_BASE"."$TARGET_TYPE"
qemu-img convert -f "$ORIG_TYPE" "$ORIG" -O raw "$TARGET_RAW"
trunc "$TARGET_RAW" "$SIZE"
sudo kpartx -a "$TARGET_RAW"
SWAP_PART=$(for i in /dev/mapper/loop0p*; do sudo vol_id $i | \
grep -q ^ID_FS_TYPE=swap && echo $i; done | head -n 1)
UUID=$(sudo vol_id "$SWAP_PART" | grep ^ID_FS_UUID= | cut -d= -f2)
sudo kpartx -d "$TARGET_RAW"
# use losetup otherwise fdisk doesn't know cylinder count
sudo losetup /dev/loop0 "$TARGET_RAW"
# FIXME: Need to automate fdisk (detect swap partition size, etc)
# I'm deleting the swap and growing the root partition, then re-adding swap
sudo fdisk /dev/loop0
sudo losetup -d /dev/loop0
sudo kpartx -a "$TARGET_RAW"
sudo e2fsck -f /dev/mapper/loop0p1
sudo resize2fs /dev/mapper/loop0p1
sudo mkswap -U "$UUID" "$SWAP_PART"
sudo kpartx -d "$TARGET_RAW"
qemu-img convert -f raw "$TARGET_RAW" -O "$TARGET_TYPE" "$TARGET"
rm "$TARGET_RAW"
# FIXME: change disk image path
sudo vi /etc/libvirt/qemu/THING
# FIXME: have the daemon notice the file change
sudo /etc/init.d/libvirt-bin restart
if [ "$ORIG" != "$TARGET" ]; then rm "$ORIG"; fi
The “trunc” command above is based on my network backups post, but is now a general script I use:
#!/usr/bin/perl
# Copyright (C) 2006-2008 Kees Cook <kees@outflux.net>, License: GPLv3
use strict;
use warnings;
my $filename = $ARGV[0];
die "Need valid size also\n" unless ($ARGV[1] =~ /^(\d+)([KMG])$/);
my $size = $1 + 0;
my $multiplier = $2;
$size *= 1024 if $multiplier =~ /^[KMG]$/;
$size *= 1024 if $multiplier =~ /^[MG]$/;
$size *= 1024 if $multiplier =~ /^[G]$/;
#die "Not trunc’ing existing file\n" if (-e $filename);
die "$filename: $!\n" if (!open(FILE,">>$filename"));
die "seek: $!\n" if (!(seek(FILE,$size,0)));
die "truncate: $!\n" if (!(truncate(FILE,$size)));
die "close: $!\n" if (!(close(FILE)));
Miguel Ruiz asked about Ubuntu security repositories. Here’s how things are done:
The “security.ubuntu.com” archive contains explicitly only the “$RELEASE-security” pockets. It is included in all Ubuntu sources.list files so that the package manager knows what the most recent security release of a package will be.
The central “archive.ubuntu.com” server (and all the Ubuntu mirrors) also contain the “$RELEASE-security” pockets, in addition to the rest of the archive (and will continue to have all pockets — which answers the core of Miguel’s question). While mirrors are not required to mirror the -security pocket, it certainly helps with the load on the primary Ubuntu archive servers.
The “security.ubuntu.com” entry is last in sources.list, giving the option of pulling an updated package from an earlier mentioned mirror (resulting in a faster download for the user, and less bandwidth used by the central Ubuntu archive servers). In the case that the mirror is behind, the package is available directly from “security.ubuntu.com”. In this way, mirrors cannot (accidentally or intentionally) “go rogue” — the latest security updates are always visible on the security archive server.
