Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Prinzipielle Fragen zur Verschlüsselung
View unanswered posts
View posts from last 24 hours
View posts from last 7 days

 
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum
View previous topic :: View next topic  
Author Message
schmidicom
l33t
l33t


Joined: 09 Mar 2006
Posts: 971
Location: Schweiz

PostPosted: Thu Aug 08, 2013 8:25 am    Post subject: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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.
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4000

PostPosted: Thu Aug 08, 2013 9:34 am    Post subject: Re: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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.
Back to top
View user's profile Send private message
schmidicom
l33t
l33t


Joined: 09 Mar 2006
Posts: 971
Location: Schweiz

PostPosted: Thu Aug 08, 2013 9:51 am    Post subject: Re: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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.
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
firefly
Advocate
Advocate


Joined: 31 Oct 2002
Posts: 4112

PostPosted: Thu Aug 08, 2013 10:10 am    Post subject: Re: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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...
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.
Back to top
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2078
Location: Konradsreuth (Germany)

PostPosted: Thu Aug 08, 2013 10:11 am    Post subject: Reply with quote

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.
Back to top
View user's profile Send private message
schmidicom
l33t
l33t


Joined: 09 Mar 2006
Posts: 971
Location: Schweiz

PostPosted: Thu Aug 08, 2013 10:14 am    Post subject: Re: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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.
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
firefly
Advocate
Advocate


Joined: 31 Oct 2002
Posts: 4112

PostPosted: Thu Aug 08, 2013 10:20 am    Post subject: Re: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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
_________________
Ein Ring, sie zu knechten, sie alle zu finden,
Ins Dunkel zu treiben und ewig zu binden
Im Lande Mordor, wo die Schatten drohn.
Back to top
View user's profile Send private message
schmidicom
l33t
l33t


Joined: 09 Mar 2006
Posts: 971
Location: Schweiz

PostPosted: Thu Aug 08, 2013 10:27 am    Post subject: Reply with quote

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?
_________________
Mich braucht jeder. Zumindest behaupten viele, ich hätte gerade noch gefehlt. ;)
GPG: 0x54A19454 - Download | (0x5E2B12A0 ist veraltet)
Back to top
View user's profile Send private message
py-ro
Veteran
Veteran


Joined: 24 Sep 2002
Posts: 1449
Location: St. Wendel

PostPosted: Thu Aug 08, 2013 11:37 am    Post subject: Reply with quote

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
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4000

PostPosted: Thu Aug 08, 2013 11:51 am    Post subject: Re: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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.
Back to top
View user's profile Send private message
l3u
Advocate
Advocate


Joined: 26 Jan 2005
Posts: 2078
Location: Konradsreuth (Germany)

PostPosted: Thu Aug 08, 2013 6:09 pm    Post subject: Re: Prinzipielle Fragen zur Verschlüsselung Reply with quote

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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Deutsches Forum (German) Diskussionsforum All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum