# Prinzipielle Fragen zur Verschlüsselung

## schmidicom

Es gibt ja Möglichkeiten die "/"-Partition zu verschlüsseln und eigentlich würde ich das bei meinem Laptop auch gerne machen nur schreckt mich der Momentane Stand der Technik dabei einfach ab. Und nun wollte ich mal ein paar Fragen zu diesem Thema loswerden die mir eine Google-suche nicht beantworten konnte.

Wieso kann der Kernel nicht von Haus aus mit einer vollen Verschlüsselung umgehen so das nicht immer mit irgendwelchen initrd's herumhantiert werden muss?

Wozu diese Verbiegungen der Device angaben von "/dev/sdaX" zu "/dev/weis/nicht/was/alles"?

Es wäre um einiges einfacher wenn der Kernel von Haus aus in der Lage wäre zu erkennen ob eine Partition verschlüsselt ist oder nicht und wenn ja ohne initrd mit einem eigenen Prompt nach einem Passwort fragen könnte oder noch besser optionale Eingaben (z.b: über verbaute Fingerprint-Reader) akzeptieren würde. Dann wäre das ganze auch nicht so aufwändig/abschreckend und infolge dessen würde es vermutlich auch häufiger angewendet werden.

----------

## mv

 *schmidicom wrote:*   

> mit einem eigenen Prompt nach einem Passwort fragen könnte oder noch besser optionale Eingaben (z.b: über verbaute Fingerprint-Reader) akzeptieren würde

 

...und hier hast Du schon Deine Antwort: Das sind alles keine nativen Aufgaben des Kernels sondern klassisches Userland-Territorium.

Statt initrd kannst Du Dir eine kleine /-Partition machen, die die benöigten Tools enthält, aber das ist natürlich auch nicht prinzipiell einfacher zu warten als eine inird.

----------

## schmidicom

 *mv wrote:*   

>  *schmidicom wrote:*   mit einem eigenen Prompt nach einem Passwort fragen könnte oder noch besser optionale Eingaben (z.b: über verbaute Fingerprint-Reader) akzeptieren würde 
> 
> ...und hier hast Du schon Deine Antwort: Das sind alles keine nativen Aufgaben des Kernels sondern klassisches Userland-Territorium.

 

Also meiner beschiedenen Meinung nach hat das mounten von "/", unabhängig davon ob es nun verschlüsselt ist oder nicht, im Userland-Territorium mal überhaupt nichts verloren. Sonst könnte man auch gleich hergehen und den kernelparameter "root=" rausschmeißen und verlangen das auch das in Zukunft ein initrd übernimmt, erst recht wenn nicht mehr mit einer festen Deviceangabe gearbeitet wird sondern mit einer PARTUUID. Bei letzterem muss der Kernel ja auch ein bisschen Eigeninitiative zeigen um das root Filesystem mounten zu können.

 *mv wrote:*   

> Statt initrd kannst Du Dir eine kleine /-Partition machen, die die benöigten Tools enthält, aber das ist natürlich auch nicht prinzipiell einfacher zu warten als eine inird.

 

Das macht die Gesamtsituation auch nicht besser, denn eine mini-root Patition kann theoretisch genauso manipuliert werden wie ein initrd das ungeschützt auf der boot Partition liegt. Und ich will mir gar nicht ausmahlen was ein heimlich ausgetauschtes initrd alles anrichten könnte.

----------

## firefly

 *schmidicom wrote:*   

> Das macht die Gesamtsituation auch nicht besser, denn eine mini-root Patition kann theoretisch genauso manipuliert werden wie ein initrd das ungeschützt auf der boot Partition liegt. Und ich will mir gar nicht ausmahlen was ein heimlich ausgetauschtes initrd alles anrichten könnte.

 

Ach aber dem unverschlüsselten kernel image unter /boot traust du? Das ließe sich genauso manipulieren, wenn die von dir geforderte Funktionalität im kernel wäre...

----------

## l3u

Wäre es nicht an sich sinnvoller, eine Partition zu verschlüsseln, die tatsächlich sensible Daten enthalten könnte? Z. B. /home, /tmp, /var/tmp etc.? Von mir aus auch /root? Dann kann der Rechner ganz normal hochfahren und vor dem Einhängen von /home nach einem Passwort fragen.

Ich mein, wenn mir einen mein Notebook klaut, dann kann er sich von mir aus gern anschauen, was ich alles für Programme drauf installiert habe …

Und nein, das Hantieren mit verschlüsselten Partitionen hat definitiv nichts im Kernel verloren.

----------

## schmidicom

 *firefly wrote:*   

>  *schmidicom wrote:*   Das macht die Gesamtsituation auch nicht besser, denn eine mini-root Patition kann theoretisch genauso manipuliert werden wie ein initrd das ungeschützt auf der boot Partition liegt. Und ich will mir gar nicht ausmahlen was ein heimlich ausgetauschtes initrd alles anrichten könnte. 
> 
> Ach aber dem unverschlüsselten kernel image unter /boot traust du? Das ließe sich genauso manipulieren, wenn die von dir geforderte Funktionalität im kernel wäre...

 

Bei einem normalen BIOS stimmt das aber bei einem UEFI gibt es Möglichkeiten dafür zu sorgen das ein ausgetauschter oder manipulierter Kernel nicht mehr akzeptiert wird. Natürlich müsste man dann im UEFI auch den Passwortschutz für die dortige Konfiguration aktivieren aber das dürfte wohl kein Problem sein.

 *l3u wrote:*   

> Wäre es nicht an sich sinnvoller, eine Partition zu verschlüsseln, die tatsächlich sensible Daten enthalten könnte? Z. B. /home, /tmp, /var/tmp etc.? Von mir aus auch /root? Dann kann der Rechner ganz normal hochfahren und vor dem Einhängen von /home nach einem Passwort fragen.
> 
> Ich mein, wenn mir einen mein Notebook klaut, dann kann er sich von mir aus gern anschauen, was ich alles für Programme drauf installiert habe …
> 
> Und nein, das Hantieren mit verschlüsselten Partitionen hat definitiv nichts im Kernel verloren.

 

Klauen ist eine Sache bei der eine Verschlüsselung sicher hilft aber wenn jemand es wirklich auf dich oder deine privaten Daten aus /home abgesehen hat wird er das Ding nicht klauen sondern so manipulieren das es nach dem du alles entsperrt hast alles automatisch per Internet an seinen "Meister" sendet.

----------

## firefly

 *schmidicom wrote:*   

>  *firefly wrote:*    *schmidicom wrote:*   Das macht die Gesamtsituation auch nicht besser, denn eine mini-root Patition kann theoretisch genauso manipuliert werden wie ein initrd das ungeschützt auf der boot Partition liegt. Und ich will mir gar nicht ausmahlen was ein heimlich ausgetauschtes initrd alles anrichten könnte. 
> 
> Ach aber dem unverschlüsselten kernel image unter /boot traust du? Das ließe sich genauso manipulieren, wenn die von dir geforderte Funktionalität im kernel wäre... 
> 
> Bei einem normalen BIOS stimmt das aber bei einem UEFI gibt es Möglichkeiten dafür zu sorgen das ein ausgetauschter oder manipulierter Kernel nicht mehr akzeptiert wird. Natürlich müsste man dann im UEFI auch den Passwortschutz für die dortige Konfiguration aktivieren aber das dürfte wohl kein Problem sein.

 

Das funktioniert indirekt auch mit einem initrd/initramfs image. Denn du kannst ein initramfs auch fest in den kernel integrieren.

https://www.kernel.org/doc/Documentation/filesystems/ramfs-rootfs-initramfs.txt

----------

## schmidicom

Ja klar aber wozu jedem der verschlüsseln will diesen unnötigen Aufwand (erstellen, testen, warten, etc. eines initrd) unterschieben wenn man das ganze auch im Kernel vereinheitlichen und zentralisieren könnte so das es letzten Endes so ziemlich jeder ohne großartigen Aufwand hin bekommt?

----------

## py-ro

Grundsätzlich:

Kernelspace = Ansteuerung der Hardware 

Userspace    = Alles was Userinteraktion erfordert

Je mehr man das Aufweicht, desto Fataler wirken sich Sicherheitslücken aus, davon ab, dass der Kernelcode unnötig wächst und verkompliziert.

Secure Boot schützt nicht vor Manipulationen vor Ort, den einmal CMOS Clear und das Passwort ist weg und der Angreifer kann tun was er will. Lokal wäre es auch kein Problem einen Hardware Keylogger anzuschließen.

Etwas mehr Schutz erreicht man, indem man ein TPM Modul verwendet, dass die Keys nur freigibt, wenn die Konfiguration des Systems nicht verändert wurde, aber auch dabei sollte man nicht auf ein zusätzliches Passwort verzichten..

Bye

Py

----------

## mv

 *schmidicom wrote:*   

> Bei einem normalen BIOS stimmt das aber bei einem UEFI gibt es Möglichkeiten dafür zu sorgen das ein ausgetauschter oder manipulierter Kernel nicht mehr akzeptiert wird.

 

Mit UEFI habe ich keine Erfahrung, aber willst Du das wirklich bei jedem Kernel-Update machen (wenn es sich überhaupt manuell konfigurieren lässt?). Außerdem kannst Du IIRC die initram auch in das kernelfile selbst packen - da ist also kein prinzipieller Unterschied.

----------

## l3u

 *schmidicom wrote:*   

> Klauen ist eine Sache bei der eine Verschlüsselung sicher hilft aber wenn jemand es wirklich auf dich oder deine privaten Daten aus /home abgesehen hat wird er das Ding nicht klauen sondern so manipulieren das es nach dem du alles entsperrt hast alles automatisch per Internet an seinen "Meister" sendet.

 

Naja … wozu willst du denn dann überhaupt irgendwas verschlüsseln? Wenn’s eh nichts bringt?! Denn diese „Manipulation“ geht ja dann wohl auch mit verschlüsselter Root-Partition.

----------

