Sicherheit von Debianpaketen (Signierung, MD5summen, etc...)

[zyta2k]

Korrigiert mich wenn ich falsch liege.

Der Maintainer baut ein Paket, in welchem Optional mittels dh_md5sums die MD5 Summen aller enthaltenen Files ins Paket geschrieben werden.
Zum Abschluss wird das Zeugs noch signiert (mit dem persönlichen GPG Key) und hochgeladen.

Auf den FTP-Master Servern (oder Incoming) können nun die Admins checken ob der Inhalt korrekt ist (mittels den Public Keys der Developper).

Soweit so gut.

Installiert man als Benutzer nun so ein Paket, so hat man auf seinem eigenen Rechner jedoch nur noch das .deb mit den (optionalen) md5summen.

Man kann also überprüfen ob die Integrität stimmt aber nicht dessen Ursprung.

Auf was ich hinaus will:
Hackt sich einer wie geschehen in einen ftp-master und ersetzt ein Programm durch ein neues (mit gefakten aber korrekten md5summen) so wird man auf dem Zielsystem nix von einem falschen Paket mitbekommen.

Man muss sich also darauf verlassen, dass das IDS oder Tripwire oder was auch immer auf den DebianServern stimmt.

Right ?

Finde ich irgendwie nicht wirklich toll sowas.
Wenn die Pakete schon siginiert werden, wieso soll dann der Enduser nicht auch davon profitieren können und die .deb's gegen den Keyring kontrollieren können ??

md5summen sind IMHO nicht für Security geeignet, da man nicht weiss ob die md5summe zu einem echten Paket gehört oder eine gefakte summe ist :/

Bin ich da auf dem Holzweg ?

[emge]

...
Installiert man als Benutzer nun so ein Paket, so hat man auf seinem eigenen Rechner jedoch nur noch das .deb mit den (optionalen) md5summen.

Man kann also überprüfen ob die Integrität stimmt aber nicht dessen Ursprung.

Auf was ich hinaus will:
Hackt sich einer wie geschehen in einen ftp-master und ersetzt ein Programm durch ein neues (mit gefakten aber korrekten md5summen) so wird man auf dem Zielsystem nix von einem falschen Paket mitbekommen.
...

Warum prüfst du die Pakete nicht selbst gegen die Schlüssel der Entwickler? M. W. bekommt man die aus dem Paket debian-keyring.

Grüße, Marco

[zyta2k]

...
Installiert man als Benutzer nun so ein Paket, so hat man auf seinem eigenen Rechner jedoch nur noch das .deb mit den (optionalen) md5summen.

Man kann also überprüfen ob die Integrität stimmt aber nicht dessen Ursprung.

Auf was ich hinaus will:
Hackt sich einer wie geschehen in einen ftp-master und ersetzt ein Programm durch ein neues (mit gefakten aber korrekten md5summen) so wird man auf dem Zielsystem nix von einem falschen Paket mitbekommen.
...

Warum prüfst du die Pakete nicht selbst gegen die Schlüssel der Entwickler? M. W. bekommt man die aus dem Paket debian-keyring.

Grüße, Marco

Weil apt mir nur das .deb Zieht !

Um es zu checken benötige ich jedoch das sigfile

bsp:

Code: Alles auswählen

gpg --verify synaptic_0.46-2_i386.deb.sig synaptic_0.46-2_i386.deb

Von wo das .sig ?
Wenn möglich automatisch

[emge]

Weil apt mir nur das .deb Zieht !

Um es zu checken benötige ich jedoch das sigfile

bsp:

Code: Alles auswählen

gpg --verify synaptic_0.46-2_i386.deb.sig synaptic_0.46-2_i386.deb

Von wo das .sig ?
Wenn möglich automatisch

Stimmt. Wenn ich mich richtig erinnere, sollte es sowas erst in nach-woody-Releases geben. Vielleicht hilft dir ja das Securing Debian Manual, besonders Kapitel 7 weiter.

Grüße, Marco

[zyta2k]

Weil apt mir nur das .deb Zieht !

Um es zu checken benötige ich jedoch das sigfile

bsp:

Code: Alles auswählen

gpg --verify synaptic_0.46-2_i386.deb.sig synaptic_0.46-2_i386.deb

Von wo das .sig ?
Wenn möglich automatisch

Stimmt. Wenn ich mich richtig erinnere, sollte es sowas erst in nach-woody-Releases geben. Vielleicht hilft dir ja das Securing Debian Manual, besonders Kapitel 7 weiter.

Grüße, Marco

Thats It


7.2 Alternative per-package signing scheme

The additional scheme of signing each and every packages allows packages to be checked when they are no longer referenced by an existing Packages file, and also third-party packages where no Packages ever existed for them can be also used in Debian but will not be default scheme.

Debian already has the capability to do this now, but implementing the policy and tools won't be started until after woody releases (so as not to slow down its release cycle).


Wär schön wenn das möglichst schnell eingeführt würde :/

[bollin]

apt 0.6.x ist in experimental

Torsten