/usr/bin/setxkbmap -option “caps:escape”

Nach einem kaputten /usr Filesystem auf einem meiner Server kam ich heute in die Verlegenheit, dass /usr/share verloren gegangen ist. Glücklicherweise lässt sich das recht einfach durch die Neuinstallation aller installierten Pakete beheben:


COLUMNS=200 dpkg -l | awk '/^[hi]i/{print $2}' | xargs apt-get -y --reinstall install


Ist natürlich nicht optimal, und eigentlich will man einen SATA-Controller, das das mit dem Hotswapping richtig hinbekommt. Aber manchmal kommt man eben doch in die Verlegenheit, im laufenden Betrieb nach neuen Festplatten suchen zu müssen. Dann hilft unter Linux dieser Befehl:

echo "0 0 0" >/sys/class/scsi_host/host<n>/scan

<n> kann man durch etwas rumwühlen in /proc/scsi/scsi rausfinden oder zumindest mal raten.

Die UUID einer Partition unter Linux bestimmt man mit dem Befehl “blkid”:

root@ariane:~# blkid /dev/md2
/dev/md2: UUID="de9657a6-f38a-4a6d-a671-b9ce64a955e4" TYPE="crypto_LUKS"

Nachdem es gestern einen Satz neue Festplatten gab, hab ich mich endlich mal entschieden, mein Truecrypt Setup zu Gunsten von dm-crypt mit Luks zu beerdigen. Im Rahmen dieser Aktion sollte auch gleich die Root-Partition mit Verschlüsselt werden. Im Prinzip ist das ja kein Problem, wenn man ein Initrd verwendet. Für Ubuntu kann in dem Fall die folgende Anleitung als Quelle dienen:
https://help.ubuntu.com/community/EncryptedFilesystemOnIntrepid

Allerdings spielt Ubuntu nicht mehr so ganz mit, sobald mehrere physical volumes ins Spiel kommen. Darüber hinaus verträgt sich Plymouth nicht so ganz mit der Passwortabfrage. Nach etwas rätseln hab ich mich dann entschlossen, die entsprechenden Vorkehrungen von Hand in das Initrd einzubauen. Konkret muss die Datei /etc/initramfs-tools/scripts/local-top/cryptoroot folgendermaßen aussehen:

EREQ="udev"

prereqs()
{
    echo "$PREREQ"
}

case $1 in
  # get pre-requisites
  prereqs)
    prereqs
    exit 0
  ;;
esac

/bin/loadkeys -q /etc/console-setup/boottime.kmap.gz
modprobe -qb dm_crypt
modprobe -qb sha256_generic

# The following command will ensure that the kernel is aware of
# the partition before we attempt to open it with cryptsetup.
/sbin/udevadm settle

if grep -q splash /proc/cmdline; then
    /bin/chvt 1
fi

## Ab hier Änderungen
status=1
while [ $status != 0 ] ; do
    password=`plymouth ask-for-password --prompt "Password?"`
    echo $password | cryptsetup luksOpen /dev/md28 lvm-pv0
    echo $password | cryptsetup luksOpen /dev/md27 lvm-pv1
    echo $password | cryptsetup luksOpen /dev/md26 lvm-pv2
    status=$?
done

Geändert haben sich hierbei die letzten 9 Zeilen, bei denen in einer Schleife so lange versucht wird, die dm-crypt-Devices zu öffnen, bis dies erfolgreich war. Hierbei wird die Passwort-Abfrage von Plymouth verwendet. Natürlich müssen die Passwörter für alle Devices die selben sein, damit dies funktioniert. Außerdem muss obiges Script noch an die lokalen Gegebenheiten des Lesers angepasst werden.

Da ich da gerade zum x-ten mal drauf reingefallen bin:

Das udev der aktuellen Sysrescuecd zeigt nach dem Booten keine Devices für die LVMs an, obwohl diese korrekt erkannt wurden. Beheben lässt sich dies einfach, indem man die Volume Group einmal deaktiviert und dann wieder neuaktiviert:

vgchange -a n
vgchange -a y

Dann tauchen die LVMs wie gewohnt unter /dev/ auf.

Möchte man unter Linux die Partitionstabelle neu einlesen, ohne das System neu zu booten, so kann man dafür den Befehl partprobe verwenden. Dies ist z.B. sinnvoll, wenn man ein Raid Device auf einer ungenutzen Partition erstellen möchte, weil man hier den Partitionstyp auf Raid-autodetect ändern muss, weil man sonst die Fehlermeldung wie z.B. “mdadm: /dev/sda1 is too small: OK” erhält.

Im Rahmen meines Seminars “Netzsicherheit und Hackerarbwehr” ist mir ein Sicherheitsfeature im Linux Kernel begegenet, dem bisher noch relativ wenig Aufmerksamkeit gewidmet wurde. Das Feature heißt “Randomize VA Space”. Hierbei handelt es sich um Address-Space-Layout-Randomization (kurz ASLR). Bei jedem Start eines Programms, wird der Anfag des Stacks innerhalb des Address-Space (AS) dieses Programmes  nicht mehr wie früher statisch, sondern zufällig bestimmt. Bei IA-32 und X86_64 wird vom anfänglichen Stackpointer eine zufälliger Integer zwischen 0 und 2^13-1 abgezogen. Insgesamt gibt es also 8192 verschiedene Adressen, an denen sich der Stackpointer befinden kann.

Der Code hierfür ist architekturspezifisch und findet sich für IA-32 z.B. unter /usr/src/linux/arch/i386/kernel/process.c :

unsigned long arch_align_stack(unsigned long sp)
{
    if (!(current->personality & ADDR_NO_RANDOMIZE) && randomize_va_space)
        sp -= get_random_int() % 8192;
    return sp & ~0xf;
}

Dies alleine bietet noch keinen ausreichenden Schutz gegen Exploits. Die Gründe dafür kann man in meiner Seminarausarbeitung nachlesen. Allerdings ist das schon recht lästig, insbesondere, wenn man nicht weiß, dass es so ein Feature gibt und man ewig nach dem Grund sucht, wieso der schöne Exploit, den man gerade geschrieben hat, dauenrd abstürzt.

Abschalten kann man das Feature übrigens mit dem Befehl:

sysctl kernel.randomize_va_space=0