Forum Debian Users Gang

Przede wszystkim wystrzegaj się takich antycznych poradników bo i tak uwalisz system i dodatkowo stracisz dane.

Elizabeth napisał(-a):

ale zawsze marzyłam żeby mieć komputer zabezpieczony prawdziwym hasłem.

Konkrety proszę.

Elizabeth napisał(-a):

ale tam piszą że trzeba skomplilować jądro z jakimiś specjalnymi opcjami

Nic nie musisz kompilować.

Elizabeth napisał(-a):

I czy w ten sposób mogę zaszyfrować nawet partycje na której jest system ?

Możesz i nawet wszystko z bootem zaszyfrować jak się uprzesz.

Linki:
https://www.howtoforge.com/tutorial/how-to-encrypt- … m-crypt-luks/
http://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/

Polecam w przypadku superbezpiecznych instalacji instalować Debiana manualnie z chroota. Masz wyżej poradnik na temat bezpiecznej instalacji DFS.

Da się zrobić szyfrowany system za pomocą instalatora ale domyślne wartości nie są jakoś specjalnie optymalne, przynajmniej dla mnie. xD

Elizabeth napisał(-a):

A po conon tam używa debootstraps ? nie da się zrobić zaszyfrowanego systemu korzystając ze standardowego instalatora ?

Była ( nie wiem jak obecnie ) taka opcja w instalatorze, aby zaszyfrować wolumin podczas instalacji. Ja tworzyłem woluminy na LVM który uprzednio cały był zaszyfrowany. Było to na Testing'u ale podejrzewam, że opcja w dalszym ciągu istnieje a może jest nieco uproszczona. Obecnie korzystam z szyfrowania całej powierzchni dysku za pomocą LUKS'a (SSD) ale w Arch'u. System działa stabilnie, nie ma spadków wydajności, wszystko odbywa się tak, jakby wolumin był utworzony bez jakiegokolwiek zabezpieczenia.
Tak na szybko pierwszy wynik w YT --> https://youtu.be/etzJAG_H5F8

Pozdrawiam

BlackEvo napisał(-a):

Tak na szybko pierwszy wynik w YT --> https://youtu.be/etzJAG_H5F8

O w.asnie chyba czegoś takiego szukałam, w każdym razie to spróbuje

Sprawdziłem, jest taka opcja. Odnośnie tej instalacji z yt z opcją szyfrowania....Zauważ, że facet tworzy osobno partycję /boot na systemie plików ext2. Ja wolalbym utworzyc zaszyfrowany LVM i dopiero w nim po kolei woluminy które Cie interesują.
/root
/swap - jeśli potrzebny - nie wiem jaki masz sprzęt
/home
W takim układzie cały dysk wraz ze wszystkimi woluminami zostaje zaszyfrowany. Po za tym, LVM to inne korzyści ( np. zmiana rozmiaru woluminu bez utraty danych, dołożenie kilku dysków i podpięcie pod wolumin lvm aby był widoczny jako jeden wielki dysk itp... ) ale to już inny temat ;)

Tu masz FAQ cryptsetup'a (to co szyfruje dyski):
https://gitlab.com/cryptsetup/cryptsetup/wikis/Freq … skedQuestions

A tu masz jak używać GPG:
https://wiki.archlinux.org/index.php/GnuPG

A tu jest przykład jak sprawdzać wiarygodność plików pobranych z netu:

╭─[morfik@morfikownia] - [~/Desktop] - [2017-12-28 15:11:58]
╰─[2] < > $ gpg --verify SHA256SUMS.sign
gpg: assuming signed data in 'SHA256SUMS'
gpg: Signature made 2017-10-14T17:49:25 CEST
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Can't check signature: No public key

╭─[morfik@morfikownia] - [~/Desktop] - [2017-12-28 15:12:16]
╰─[2] < > $ gpg --search-keys DF9B9C49EAA9298432589D76DA87E80D6294BE9B   
gpg: data source: https://37.191.226.104:443
(1)     Debian CD signing key <debian-cd@lists.debian.org>
          4096 bit RSA key 0xDA87E80D6294BE9B, created: 2011-01-05
Keys 1-1 of 1 for "DF9B9C49EAA9298432589D76DA87E80D6294BE9B".  Enter number(s), N)ext, or Q)uit > 1
gpg: key 0xDA87E80D6294BE9B: 48 signatures not checked due to missing keys
gpg: key 0xDA87E80D6294BE9B: public key "Debian CD signing key <debian-cd@lists.debian.org>" imported
gpg: marginals needed: 3  completes needed: 1  trust model: pgp
gpg: depth: 0  valid:   3  signed:   0  trust: 0-, 0q, 0n, 0m, 0f, 3u
gpg: next trustdb check due at 2018-08-24
gpg: Total number processed: 1
gpg:               imported: 1

╭─[morfik@morfikownia] - [~/Desktop] - [2017-12-28 15:12:56]
╰─[0] < > $ gpg --verify SHA256SUMS.sign
gpg: assuming signed data in 'SHA256SUMS'
gpg: Signature made 2017-10-14T17:49:25 CEST
gpg:                using RSA key DF9B9C49EAA9298432589D76DA87E80D6294BE9B
gpg: Good signature from "Debian CD signing key <debian-cd@lists.debian.org>" [unknown]
gpg: WARNING: This key is not certified with a trusted signature!
gpg:          There is no indication that the signature belongs to the owner.
Primary key fingerprint: DF9B 9C49 EAA9 2984 3258  9D76 DA87 E80D 6294 BE9B

╭─[morfik@morfikownia] - [~/Desktop] - [2017-12-28 15:13:33]
╰─[0] < > $ sha256sum -c SHA256SUMS
debian-9.2.1-amd64-netinst.iso: OK
...

Plik SHA256SUMS.sign ma podpis, którym można zweryfikować integralność pliku z sumami kontrolnymi, tj. plik SHA256SUMS. Podpis jest składany prywatnym kluczem GPG, to trzeba pobrać jego publiczny odpowiednik w przypadku, gdy się go nie ma (tak jak wyżej). Sygnatura jest poprawna ale nie mam określonego zaufania do klucza, więc nie można zweryfikować czy faktycznie należy on do tej osoby co rzekomo wystawiła sygnaturę — przydałoby się jakoś to zweryfikować by mieć pewność, choć w tym przypadku można założyć, że wszystko jest w porządku. Na koniec jest porównywalna suma kontrolna pobranego pliku z tym co zostało zapisane w pliku z sumami kontrolnymi i tutaj też wszystko się zgadza, czyli plik jest taki jak powinien być. To tak z grubsza. xD

Ostatnio edytowany przez morfik (2017-12-28 15:24:40)

Co to znaczy, że nie ma określonego zaufania do klucza ? Gdzie jest ta baza zaufanych kluczy ?

No to znaczy, że każdemu kluczowi można ustawić poziom zaufania, a jak się tego nie robi, to domyślnie klucz jest niezaufany. A baza kluczy jest, np. tutaj:

$ gpg --list-keys
/home/morfik/.gnupg/pubring.kbx
...

A zaufanie do klucza się ustawia via:

$ gpg --edit-key debian-cd@lists.debian.org
gpg (GnuPG) 2.2.3; Copyright (C) 2017 Free Software Foundation, Inc.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.


pub  rsa4096/0xDA87E80D6294BE9B
     created: 2011-01-05  expires: never       usage: SC
     trust: unknown       validity: unknown
sub  rsa4096/0x642A5AC311CD9819
     created: 2011-01-05  expires: never       usage: E
[ unknown] (1). Debian CD signing key <debian-cd@lists.debian.org>

gpg> trust
pub  rsa4096/0xDA87E80D6294BE9B
     created: 2011-01-05  expires: never       usage: SC
     trust: unknown       validity: unknown
sub  rsa4096/0x642A5AC311CD9819
     created: 2011-01-05  expires: never       usage: E
[ unknown] (1). Debian CD signing key <debian-cd@lists.debian.org>

Please decide how far you trust this user to correctly verify other users' keys
(by looking at passports, checking fingerprints from different sources, etc.)

  1 = I don't know or won't say
  2 = I do NOT trust
  3 = I trust marginally
  4 = I trust fully
  5 = I trust ultimately
  m = back to the main menu

Your decision? 3

pub  rsa4096/0xDA87E80D6294BE9B
     created: 2011-01-05  expires: never       usage: SC
     trust: marginal      validity: unknown
sub  rsa4096/0x642A5AC311CD9819
     created: 2011-01-05  expires: never       usage: E
[ unknown] (1). Debian CD signing key <debian-cd@lists.debian.org>
Please note that the shown key validity is not necessarily correct
unless you restart the program.

gpg> save
Key not changed so no update needed.

I tak dalej ale trzeba pierw pogadać z właścicielem i sprawdzić czy faktycznie on jest tym za kogo się podaje. Bez tego określanie zaufania do klucza mija się z celem. xD

A poza tym w przykładzie który podałeś sprawdziłeś podpis na pliku SHA256SUMS.sign, a skrót obrazu porównałeś z plikiem SHA256SUMS

Nie mam przekonania czy to prawidłowa procedura, to są przecież dwa różne pliki

Mam takie małe wrażenie, że ja mogę conieco wiedzieć o tym co robię. xD

Ale tak już śmiechy na bok, to ci wyjaśniam, że suma kontrolna weryfikuje integralność danych w pliku, tj. tego co pobierasz przez net na dysk. Ten co stworzył plik, wygenerował jego sumę kontrolną i umieścił ją w pliku SHA256SUMS . Ten plik jest podatny na zmianę, np. przez kogoś kto by chciał podmienić plik na serwerze. Wtedy wystarczyłoby zmienić sumę kontrolną w pliku i użytkownik by myślał, że pobrał oryginalny plik, a nie ten podmieniony. Dlatego stosuje się podpis tego pliku przy pomocy GPG, gdzie każda zmiana zawartości SHA256SUMS będzie skutkować błędem przy sprawdzaniu sygnatury z wykorzystaniem pliku  SHA256SUMS.sign . KPW? xD

edit: a chyba już wiem o co chodzi SHA256SUMS.sign musi być w tym samym katalogu co SHA256SUMS gdy wykonujemy gpg --verify ?

No tak.

Ostatnio edytowany przez morfik (2017-12-28 16:20:32)

Elizabeth napisał(-a):

No to skąd mam wiedzieć na początku który klucz jest zaufany ?

No nie możesz, dlatego klucz jest domyślnie niezaufany. xD Z reguły na kluczach masz mail właściciela oraz też sygnatury innych osób, które ten klucz podpisały. Jeśli żadnej z tych osób nie znacz (właściciela oraz tych co podpisały), to klucz zawsze będzie dla ciebie niezaufany. Możesz to zmienić pisząc do gościa z prośbą o uwierzytelnienie, np. via rozmowa telefoniczna/spotkanie, itp, tak by wykazała, że to do niej należy klucz i tak ludzie robią i tak powinno się robić, choć trochę kłopotów z tym jest. xD

Elizabeth napisał(-a):

Ten klucz do którego zostanę odesłana ze strony z obrazem nie jest bardziej zaufany niż dowolny inny plik na tej stronie, więc sprawdzenie podpisu skrótu obrazu tym kluczem ani trochę nie zwiększa bezpieczeństwa.

No ten proces jedynie ma na celu zapewnienie, że dane nie zostały zmienione gdzieś po drodze. Jak cały proces przebiegł poprawnie (tak jak w tym przypadku), to decyduje zaufanie do klucza. I jeśli ufasz kluczowi, to wszystko jest ok. Jeśli nie ufasz, to plik może nie być ok. xD Więc albo masz przesłanki, że ten klucz należy do tego do kogo powinien albo zweryfikuj umawiając się na spotkanie czy coś. xD

Elizabeth napisał(-a):

I co robi polecenie gpg --fingerprint ? oraz czym się różni opcja --search-keys od --recv-keys lub --recv-key ?

Zajrzyj sobie do:

$ man gpg

No to idź poznaj -- kiedyś ludzie tak robili, zanim fejsa wynaleźli. xD

Albo podam ci hint'a, który może wskazywać, że ktoś jest tym za kogo się podaje.

Np. ja występuję w sieci jako Mikhail Morfik Morfikov. To jest fałszywa tożsamość (tak wiem, że nie wszyscy o tym wiedza jeszcze xD) ale ludzie mnie pod tym nazwiskiem znają. I w zasadzie nikogo nie interesuje to jak ja się nazywam naprawdę, tylko to co sobą reprezentuję, np. co robię w sieci. Mam konta na całej masie portali, np. na github (https://github.com/morfikov/files/commits/master) -- tutaj są moje komity, które od czasu do czasu zamieszczam aktualizując pewne rzeczy w swoim repozytorium. To repozytorium nie powstało z dnia na dzień tylko już ma parę lat. Wszystkie komity są podpisane (tam pisze Verified). Jak klikniesz na ten przycisk, to zostanie pokazany ID klucza, którym komit jest podpisany. W tym przypadku wszystkie są podpisane CD046810771B6520, no i sprawdzasz do kogo należy klucz i od jak dawna:

$ gpg --search-keys 0xCD046810771B6520
gpg: data source: https://37.191.226.104:443
...
        Mikhail Morfikov
...
          4096 bit RSA key 0xCD046810771B6520, created: 2013-11-13, expires: 2018-08-26
Keys 1-1 of 1 for "0xCD046810771B6520".  Enter number(s), N)ext, or Q)uit >

Widać, że do tej osoby, która również się nazywa Mikhail Morfikov, więc mogę to być ja, tj. ten user co tutaj pisze. xD Nie trzeba się ze mną na spotkanie umawiać, wystarczy korelować informacje, by mieć pewne przesłanki, że ten klucz należy do tego, do kogo powienien. Jeśli teraz ja bym wypuścił płytkę z jakimś debianem i podpisał sumy kontrolne swoim kluczem GPG, i to byłby ten sam klucz co tam na githubie, to już możesz mu ufać, przynajmniej przez jakiś czas. xD

Ostatnio edytowany przez morfik (2017-12-28 17:06:59)

W sumie to masz tam dwa dyski, to może być na obu i później będą decydować ustawienia w biosie, np. bez podpiętego drugiego dysku uruchomi się windows.

Ostatnio edytowany przez morfik (2017-12-28 17:55:03)

Będzie dual jak będą dwa dyski -- będzie do wyboru z menu podczas startu systemu. Ale jak nie podłączysz drugiego dysku, to system wystartuje z pierwszego automatycznie.