Bei mir ist FileVault2 aktiviert und dementsprechend kommt relativ früh ein Login, damit anschliessend die verschlüsselte Disk gelesen werden kann. Passwort eingegeben… Falsch. Nochmals… immer noch falsch. Und ein drittes Mal und wirklich ganz genau hingeschaut, dass es richtig ist. Falsch! Hmmm… das wird doch wohl nicht plötzlich auf das US-Layout gewechselt haben. Ein weiterer Versuch und -aha- plötzlich funktionierts…

Beim suchen, ob man das wieder auf DE_ch ändern kann, bin ich aber auf etwas anderes Interessantes gestolpert:

Passware Kit Forensic 11.3 knackt FileVault2 Schutz

Der verlinkte Artikel ist bereits einige Tage alt, aber grundsätzlich offenbar schon länger bekannt, da dieser Fehler bereits mit 10.7.2 gefixt wurde:

Kernel
Available for: OS X Lion v10.7 and v10.7.1, OS X Lion Server v10.7 and v10.7.1
Impact: A person with physical access may be able to access the user’s password
Description: A logic error in the kernel’s DMA protection permitted firewire DMA at loginwindow, boot, and shutdown, although not at screen lock. This update addresses the issue by preventing firewire DMA at all states where the user is not logged in.

CVE-ID

CVE-2011-3215 : Passware, Inc.

Quelle: http://support.apple.com/kb/HT5002?viewlocale=en_US

Offenbar scheint das erst jetzt so richtig aufzupoppen. Konkret gefunden habe ich z.B. bei heise noch nichts darüber, ausser dass einige Benutzer meldeten, dass ihr System mit aktiviertem FileVault nach dem Upgrade auf 10.7.2 nicht mehr bootete.

Und um auf mein ursprüngliches Problem zurückzukommen: Eine Lösung habe ich noch nicht gefunden.

Damit ich das auf keinen Fall wieder suchen muss, veröffentliche ich es hier:

Das Programm “Keychain Access” öffnen.

Die “Preferences” aufrufen und “Show keychain status in menu bar” aktivieren.

Voilà, c’est ça.

Einige Features und weitere Informationen wurde in diesem Post beschrieben

Da ich auf meinem Debian Lenny Server virtuelle Maschinen unter Xen laufen habe und auf einen fast unterbruchsfreien Upgrade angewiesen bin, habe ich den ersten Teil des Upgrades ausgiebig getestet. Es wäre gelogen, wenn mir das Ganze nicht etwas Kopfzerbrechen bereitet hätte…

Wo will ich hin:

• Debian Lenny VMs (DomU) auf Debian Squeeze aktualisieren
• Debian Lenny Xen Hypervisor (Dom0) auf Debian Squeeze aktualisieren

Der erste Teil befasst sich mit dem Upgrade der VMs. Nach einem finalen apt-get update && apt-get -u upgrade von Debian Lenny wird die sources.list für Squeeze angepasst. Anschliessend wird apt-get update && apt-get -u dist-upgrade ausgeführt. Hier kann man mehr oder weniger bestätigen, was vorgeschlagen wird (je nach installierten Applikationen kann es einige Anpassungen geben). Der Upgrade sah dann auch ziemlich gut aus. Leider kam nach einem erneuten Start der VM folgende Fehlermeldung:

dom0:~# xm create -c /etc/xen/guests/domU1.cfg
Using config file "/etc/xen/guests/domU1.cfg".
Error: Boot loader didn't return any data!

Na toll… Anzahl funktionierende VMs: -1

Nach unzähligen weiteren Versuchen (man arbeitet ja zum Glück mit LVM Snapshots und fängt mit einer Test VM an) und stundenlanger Recherche habe ich die Lösung herausgefunden.

Das Problem wird durch pygrub und grub2 verursacht. grub2 arbeitet neu mit “named partitions” und damit kommt pygrub nicht klar. Aus diesem Grund verzichten wir (vorübergehend) auf grub2 und installieren den alten grub wieder. Mehr Infos hier, hier und hier.

Die Lösung:

Nach dem Upgrade auf Debian Squeeze und vor dem Reboot muss grub-legacy installiert werden. Dabei wird auch gleich grub2 deinstalliert (ich habe die Config ebenfalls gelöscht (--purge)). Anschliessend habe ich zur Sicherheit das alte Kernel Image von Debian Lenny nochmals installiert. Dieses sollte man unbedingt zur Hand haben.

Anschliessend kann man rebooten. In meinem Fall hat das geklappt und die VM kommt wieder hoch.

Nun stellt sich die Frage was passiert, wenn nun Dom0 auf Squeeze aktualisiert wird. Ich gehe davon aus, dass man vorgängig auf allen VMs grub2 installieren muss, damit die VM auch mit Xen 4 wieder hochfährt. Das werde ich ebenfalls ausgiebig testen, um dann auf dem produktiven System keine Überraschungen erleben zu müssen.

Interessante Features (für mich) sind FileVault 2, Launchpad und die neuen Sicherheitsfeatures. Leider fehlen aber nach wie vor Focus-follows-Mouse und Auto-Raise-Window. Das vermisse ich nach wie vor…

Alle Features im Überblick sind hier zu finden.

Desweiteren haben sie ihren neuen Dienst iCloud vorgestellt. Ein weiterer Anbieter, der dem Cloud Hype nachrennt. Ich verstehe nach wie vor nicht, wie man seine Daten extern lagern kann. Hauptsache es ist cool…

Und iOS5 wurde ebenfalls noch angekündigt. Mit iOS5 ist iCloud offenbar gratis dabei… Dabei wird mein iPhone schon seit geraumer Zeit nicht mehr unterstützt und mein Wecker wird am 1. Januar 2012 einmal mehr den Dienst verwehren.

Wenn man nur temporär als root arbeiten will, kann genauso gut folgenden Befehl verwenden, um die Bash Shell mit root Rechten zu starten:

sudo bash

Aber jetzt zum eigentlichen Vorhaben. So gehts:

Root Account aktivieren

1. Terminal öffnen
2. dsenableroot
3. Passwörter eingeben, respektive setzen.

Live sieht das so aus:

apfeleimer:~ andy$ dsenableroot
username = andy
user password:
root password:
verify root password:

dsenableroot:: ***Successfully enabled root user.

Root Account deaktivieren

1. dsenableroot -d
2. Passwort eingeben

Und das Deaktivieren sieht dann so aus:

apfeleimer:~ andy$ dsenableroot -d
username = andy
user password:

dsenableroot:: ***Successfully disabled root user.

Wer ein Shell Script mit dem wohlklingenden Namen klickmich.sh auf dem Desktop hat und dies per Doppelklick ausführen möchte, muss leider feststellen, dass diese Datei nicht ausgeführt wird, sondern mit einem Programm (in meinem Fall XCode) geöffnet wird.

Das ist etwas schade… :)

Wenn man aber klickmich.sh in klickmich.command umbenennt, dann verhält sich Mac OS X so, wie man es eigentlich erwartet. Das Shell Script wird ausgeführt. Aber Achtung! Bedingung ist, dass das Shell Script mit dem executable Bit versehen ist. Dies wird erreicht, indem man im Terminal

chmod +x /path/to/klickmich.command

ausführt. Ein ausführlicher Artikel über Dateiberechtigungen findet sich ebenfalls auf apfelschwein.net.

Tags: Mac+OS+X, .command, Shell

Tags: Mac+OS+X, Shutdown, Reboot, Sleep

diskutil list

/dev/disk0
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:      GUID_partition_scheme                        *500.1 GB   disk0
1:                        EFI                         209.7 MB   disk0s1
2:                  Apple_HFS Macintosh HD            499.8 GB   disk0s2
/dev/disk1
#:                       TYPE NAME                    SIZE       IDENTIFIER
0:     Apple_partition_scheme                        *999.5 GB   disk1
1:        Apple_partition_map                         32.3 KB    disk1s1
2:                  Apple_HFS andy                    999.5 GB   disk1s2

Die erste Disk ist die interne Disk vom Macbook Pro, die zweite ist eine externe USB Festplatte.

Ein ntpdate swisstime.ethz.ch funktionierte nicht:

root@zelia:~# ntpdate swisstime.ethz.ch
Error resolving swisstime.ethz.ch: Name or service not known (-2)
28 Dec 16:27:34 ntpdate[1908]: Can't find host swisstime.ethz.ch: Name or service not known (-2)

28 Dec 16:27:34 ntpdate[1908]: no servers can be used, exiting


Löste man das aber manuell mit host swisstime.ethz.ch auf, klappte es:

root@zelia:~# host swisstime.ethz.ch
swisstime.ethz.ch is an alias for swisstime.ee.ethz.ch.
swisstime.ee.ethz.ch has address 129.132.2.21


Die typischen Einstellungen in /etc/resolv.conf, /etc/nsswitch waren alle in Ordnung.

Während meiner Recherche bin ich auf verschiedene Quellen aufmerksam gewordern, die die Ursache IPv6 zuschreiben. Aus diesem Grund habe ich IPv6 deaktiviert. Leider war es das noch nicht…

Dann fand ich noch den Bug #541167, der ziemlich gut mein Problem beschreibt.

Die Probleme schienen bei ntp, ntpdate und apt aufzutreten, die alle die getaddrinfo() Funktion von libc6 benutzten.

Ein tcpdump führte folgendes zu Tage:
Der funktionierende Aufruf mit host:

16:40:08.078351 IP 172.16.6.40.57131 > 172.16.6.1.53: 55253+ A? swisstime.ethz.ch. (35)
16:40:08.091726 IP 172.16.6.1.53 > 172.16.6.40.57131: 55253 2/0/0 CNAME swisstime.ee.ethz.ch., A 129.132.2.21 (78)
16:40:08.091997 IP 172.16.6.40.52537 > 172.16.6.1.53: 11428+ AAAA? swisstime.ee.ethz.ch. (38)
16:40:08.104752 IP 172.16.6.1.53 > 172.16.6.40.52537: 11428- 0/0/0 (38)
16:40:08.104859 IP 172.16.6.40.57842 > 172.16.6.1.53: 29048+ MX? swisstime.ee.ethz.ch. (38)
16:40:08.117815 IP 172.16.6.1.53 > 172.16.6.40.57842: 29048- 0/0/0 (38)

Und nun mit ntpdate, das getaddrinfo() benutzt:

16:43:36.497574 IP 172.16.6.40.45926 > 172.16.6.1.53: 40071+ A? swisstime.ethz.ch. (35)
16:43:36.497577 IP 172.16.6.40.45926 > 172.16.6.1.53: 25658+ AAAA? swisstime.ethz.ch. (35)
16:43:36.510563 IP 172.16.6.1.53 > 172.16.6.40.45926: 40071 2/0/0 CNAME swisstime.ee.ethz.ch., A 129.132.2.21 (78)
16:43:36.513496 IP 172.16.6.1.53 > 172.16.6.40.45926: 25658- 0/0/0 (35)
16:43:36.513564 IP 172.16.6.40.56470 > 172.16.6.1.53: 40071+ A? swisstime.ethz.ch. (35)
16:43:36.513613 IP 172.16.6.40.56470 > 172.16.6.1.53: 25658+ AAAA? swisstime.ethz.ch. (35)
16:43:36.526550 IP 172.16.6.1.53 > 172.16.6.40.56470: 40071 2/0/0 CNAME swisstime.ee.ethz.ch., A 129.132.2.21 (78)
16:43:36.529225 IP 172.16.6.1.53 > 172.16.6.40.56470: 25658- 0/0/0 (35)
16:43:36.529298 IP 172.16.6.40.59051 > 172.16.6.1.53: 2262+ A? swisstime.ethz.ch.lab.init0.ch. (48)
16:43:36.529347 IP 172.16.6.40.59051 > 172.16.6.1.53: 51840+ AAAA? swisstime.ethz.ch.lab.init0.ch. (48)
16:43:36.529749 IP 172.16.6.1.53 > 172.16.6.40.59051: 2262 NXDomain- 0/0/0 (48)
16:43:36.530108 IP 172.16.6.1.53 > 172.16.6.40.59051: 51840 NXDomain- 0/0/0 (48)


Es sieht effektiv danach aus, als hätte libc6 Probleme, wenn der Nameserver für den AAAA Record eine Null-Response bekommt.

Als allerletzte Option habe ich den Nameserver (interner DNS Server des Swisscom ADSL Routers [Motorola 3347]) auf die externen von Bluewin gewechselt:

root@zelia:~# cat /etc/resolv.conf
nameserver 195.186.1.111
nameserver 195.186.1.110


Und schwupps… Jetzt gehts!

Fazit: Der DNS Server des Swisscom ADSL Routers ist kaputt.