SELinux und Openmoko

3. März 2009 | Von | Kategorie: Outside | SELinux | AppArmor

Ich hatte letzte Tage die Gelegenheit mit dem Openmoko Neo Freerunner zu spielen. Inzwischen ist es möglich mit dem Qi Bootloader ohne flashen einen neuen Kernel zu booten. Ich wurde gebeten, zu testen ob SELinux hier laufen würde. Die Vorraussetzungen waren gegeben. Die SD-Card von der das Handy bootete verwendete das ext3-Dateisystem. Als Distribution wurde Debian verwendet. Der Zugriff erfolgte von einem Laptop über eine Netzwerkverbindung auf das Handy. Die Netzwerkverbindung wurde über das USB-Kabel hergestellt. Die Anmeldung erfolgte dann mit der SSH.

Also ran.

Zunächst musste ich mir einen neuen Kernel bauen. Der verwendete Kernel unterstützte weder SELinux noch Extended Attributes im Dateisystem. Der Kernelbau war mit der Toolchain des Openmoko-Projektes und dem 2.6.29 Kernel von dem Openmoko-Kernel-Developer Andy schnell gemacht. Wenige Anpassungen in der Kernel-Config und SELinux war aktiv.Der Kernel wurde so konfiguriert, dass SELinux im Permissive Modus eingeschaltet wurde.

Nach der Installation des neuen Kernels wurden die benötigten Debian Lenny Pakete installiert: aptitude update; aptitude install selinux-basics

Damit waren die 500 MB Dateisystem fast komplett voll. Schnell ein apt-get clean um die installierten Paketkopien zu entfernen. Mit selinux-activate wurde SELinux aktiviert und neu gebootet. Der Befehl selinux-activate erzeugt die Datei /.autorelabel und passt einige Dateien an (z.B. PAM) . Bei dem Reboot werden dann alle Dateien passend gelabelt. Auf dem Display konnte das auch gut verfolgt werden.

Ergebnis:

Das Handy war immer noch pingbar. Die Anmeldung per SSH funktionierte auch, aber leider wurde ich vor dem Öffnen der Konsole wieder rausgeworfen. Die Authentifizierung klappte aber (ssh -v).

Fehlersuche:

Jetzt stellte sich als sehr angenehm der neue Bootloader heraus. Ich habe einfach die Karte aus dem Handy entnommen, im Laptop gemounted und konnte die Bootoptionen und auch den Kernel ändern. Nach hinzufügen von selinux=0 in der Append-Zeile des Kernel habe ich erneut gebootet um den Kernel zu testen und die Protokolle zu analysieren. Nun funktionierte alles. Der Kernel war also in Ordnung und verfügte über alle notwendigen Devices auch für die SSH. Die Protokolle waren ein Reinfall, da es keine gab. Also habe ich noch die Pakete sysklogd und den Audit-Daemon installiert, den Kernel wieder zurückgesetzt und … vor dem Neustart mir nochmal die Policy angesehen. Ein semodule -l zeigte keine Module? Anscheinend hat die automatische Erkennung bei der Installation der Policy nicht geklappt. Normalerweise versucht Debian bei der Installation der Policy automatisch alle benötigten Module selbst zu erkennen und automatisch zu aktivieren. Also habe ich selbst die Module aktiviert und neu im SELinux Permissive Mode gebootet. Wieder war eine Anmeldung nicht möglich.

Im Permissive Modus sollte SELinux keine Anmeldung verhindern. Daher konnte es nicht an SELinux liegen. Auf der anderen Seite war die Anmeldung mit dem identischen Kernel und deaktivierten SELinux möglich. Ich untersuchte nochmal die SELinux Policy Module und stellte fest, dass das unconfined.pp Modul noch nicht geladen wurde. Nach dem Hinzufügen ein erneuter Reboot.

Jetzt funktionierte die Anmeldung und ich erhielt eine Shell per SSH. Wie konnte das sein? Im Permissive Modus sollte die Policy doch eigentlich egal sein? Die SSH versucht bei der Anmeldung jedem Benutzer seinen eigenen Kontext zuzuweisen. Nachdem ich mich also mit Benutzernamen und Kennwort korrekt authentifiziert hatte, versuchte mir der SSH-Daemon die Default-Rolle und Typ unconfined_r:unconfined:t zuzuweisen. Diese existierten jedoch noch nicht. Hierdurch kam es zu einem Fehler in dem SSH-Daemon, der die Verbindung abbrach.

SELinux und Openmoko?

Nach ein zwei weiteren Reboots hatte ich dann auch alle Audit-Meldungen gesammelt, die von dem SELinux-Sub-System ansonsten noch ausgegeben wurden, so dass ich die Policy mit eigenen Modulen erweitern konnte, die dann ein Boot und eine Anmeldung auch im Enforcing Modus erlaubten. Leider war das nur ein schneller Hack. Das Openmoko verwendet einige besondere Devices (z.B. /dev/mtdblock*), die in der Default-Debian-Policy noch nicht berücksichtigt werden. Dadurch haben diese Devices den falschen Label. Hier müsste die Policy noch besser angepasst werden, wofür mir die Zeit fehlte, da ich das Handy wieder abgeben musste. Vielleicht werde ich mir selbst eins kaufen um damit zu spielen 😉

Post to Twitter Post to Yahoo Buzz Post to Delicious Post to Digg Post to Facebook Post to Ping.fm Post to Reddit

Tags: | |

Schreibe einen Kommentar

Fühle dich ermuntert einen Kommentar, Anmerkungen, Hinweise oder deine Ideen zum Thema zu hinterlassen. Wir freuen uns über deine Rückmeldung.