Forum Debian Users Gang

Ja się mogę wypowiedzieć co do plików tym w OO
Wszystko co tworzy user ma w swoim katalogu domowym w ukrytym katalogu .openoffice/.libreoffice

k4misiek napisał(-a):

Takie programy jak mlocate mają swoją bazę danych pod / więc nawet jak zaszyfrujesz /home to nazwy plików/katalogów z tej partycji i tak będziesz można odczytać.

ls -l /var/lib/mlocate/mlocate.db                                                           
-rw-r----- 1 root locate 84153973 08-16 07:10 /var/lib/mlocate/mlocate.db

wszystkie pliki, których zawartość się domyślnie zmienia w czasie normalnej pracy systemu , są w katalogu/partycji var.

Jeśli var i home jest na osobnych  partycjach, to spokojnie można / dać read-only, o ile przy uruchomieniu nie zmienia się konfiguracja w /etc - np skutek dhcp.

Ale to też można rozwiązać robiąc dowiazania do np /var/etc dla kilku plików.

Ja używam LUKSa od 2 lat. Jest to (w moim przypadku) LVM, wewnątrz którego jest 7 dysków logicznych upakowanych na jednej zaszyfrowanej partycji 40gb. W skład grupy wchodzą: /, /tmp, /var, /var/log, /home, /var/cache/apt/archives oraz swap. Dodatkowo cache przeglądarek oraz katalogi /home/user/.cache,  /home/user/.macromedia podlinkowane są do /tmp i co restart systemu cały cache jest czyszczony. Ale to tak by fragmentację plików ograniczyć. No i ewentualnie gdyby ktoś chciał podmontować /tmp z opcją noexec. Ja się powoli do tego przymierzam ale jeszcze muszę trochę doczytać.

W przypadku zaszyfrowania tylko partycji /home, masz pełno przecieków, przy pomocy których można zidentyfikować to, co robiłeś na sprzęcie. Choćby przestrzeń wymiany (jeżeli używasz), na którą są zgrywane rozmaite informacje, łącznie z kluczami i hasłami do twojego zaszyfrowanego /home. Przestrzeń wymiany jest bardzo pomocna dla policji, o ile nie szyfrujesz jej. Następny w kolejności do pomocy idzie katalog /tmp.

W linuxie masz restrykcyjne przepisy co do tego gdzie, kto, co może zapisywać. Domyślnie zwykły user ma możliwość zapisu tylko katalogu /home i /tmp. Dlatego też program wywołany przez określonego użytkownika nie-roota, nie może sobie zapisywać danych gdzie chce, tak jak miało to miejsce w przypadku windows. Nie używam windowsa od ponad 2 lat i chyba coś w tej kwestii się zmieniło. Na windowsie xp, gdzie domyślnie miałeś konto administratora, wirusy mogły sobie spokojnie się wykonywać, bo miały prawa administratora systemu. W linuxie tak łatwo nie ma.

Co do live-cd. Generalnie rzecz biorąc musisz mieć te pakiety zainstalowane:

cryptsetup lvm2 libdevmapper-dev.

Tak wiem to live-cd, ale instalator pakietów działa normalnie, tyle, że instaluje pakiety w RAMie. Po resecie i tak nie będzie po nich śladu. Dlatego jak nie widzi ci LVM, dociągasz pakiety.

Ja korzystałem głównie z konsoli w przypadku live-cd. Prosta regułka przy dostępie do LVM:

Otwieranie zaszyfrowanej partycji i nadanie jej nazwy koxik, (wymagane hasło dostępu)

cryptsetup luksOpen /dev/sda2 koxik

pvscan i vgscan używasz do sprawdzenia co jest wewnątrz zaszyfrowanej partycji. Powinno ci wyrzucić nazwę grupy LVM.

Następnie za pomocą

vgchange -a y

aktywujesz sobie dostępne grupy. I jeżeli wszystko poszło sprawnie to po wydaniu lvscan powinieneś ujrzeć swoje dyski wirtualne w LVM. Później już tylko montujesz je i możesz na nich operować.

Jak kończysz robotę to odmontowujesz i wydajesz kolejno:

vgchange -a n
cryptsetup luksClose koxik

Oczywiście wszystkie operacje wykonujesz jako administrator albo przez sudo.

I to cała filozofia korzystania z zaszyfrowanego LVM pod live-cd. Jeżeli masz tylko LVM, bez szyfrowania, to wtedy nie używasz cryptsetup luksOpen. Za to cała reszta pozostaje taka sama.

DadaD napisał(-a):

Czy tylko w przypadku awarii utrudni życie lub nawet uniemożliwi dostęp do danych

Na przestrzeni 2 lat nie zdarzyła się żadna utrata danych z zaszyfrowanego LVM. Było kilka zaników napięcia, jednak starałem się to ograniczyć do minimum, bo jak nie patrzeć dane jako takie (te wewnątrz woluminów) cierpią, gdy system jest zamykany nieprawidłowo i w tym czasie jest dokonywany zapis plików na dysku. Swoją drogą to już od wielu wielu lat mam dyski zaszyfrowane truecryptem i też nigdy mi się nie zdarzyło bym utracił z nich jakieś dane. A zasada jest dokładnie taka sama co w przypadku szyfrowania systemowej partycji.

Jeżeli nie odczuwasz spowolnienia działania systemu w wyniku szyfrowania, to albo masz dobry procesor albo używasz słabego szyfru. Jeżeli założysz potrójne szyfrowanie w truecrypcie, gwarantuje ci, że zapis danych mocno ucierpi. Przy pojedynczym szyfrowaniu AES-256, domowe dyski nawet przy słabszym procesorze nie odczują znacznej różnicy w zapisie danych. Natomiast jeżeli weźmiesz już bardziej wypasione dyski, typowo serwerowe, to na nich spadek wydajności już będzie obserwowalny. Ale i tak duża rolę odgrywa w całym procesie szyfrowania procesor.

Sorry, że taki długi tekst wyszedł :]

Używam od jakiegoś czasu szyfrowanego LVMa (ale tylko mój własny katalog domowy). Zamiast hasła korzystam z klucza umieszczonego na pendriveie/karcie pamięci. Tego jestem w stanie zalogować się do systemu ale podmontuje mi pustkę ;)
Klucz generowany na podstawie /dev/random o rozmiarze 4k - trochę się naczekałem aż mi go wypluje (niestety link na podstawie którego robiłęm wygasł....) Klucz szyfrowany aes-256-cbc z hashem md5. /tmp i /var/tmp montowane jako tmpfs, swapa nie używam (jak się w debianie bawiłem w szyfrowane LVMy to swap szyfrowany był losowym kluczem). Procek się nudzi cały czas ale niestety daje się odczuć spadek wydajności dysku a do powolnych to on nie należy (hybrydowy seagate 7.2k rpm z 4GB flashowej pamięci - dysk sam alokuje najczęściej używane sektory na pamięci ssd).

Swoje newralgiczne dane trzymam w $HOME, reszta leży na zewnątrz (zresztą $HOME ma tylko 10GB). Jak zaczynałem zabawy z pingwinem to ustawiłem sobie "paranoid mode" :)
/
/home
/var
/usr
swap

każde szyfrowane innym hasłem do tego pass na bios i bootloader :) Także zanim się zalogowałem musiałem wklepać 8 różnych haseł ;] Niestety było to za czasów gdy korzystałem z lapka, który miał zrypane gniazdo zasilania (nawet bajpasy - nie pomagały) i zbyt gwałtowne czy nieuważne przesunięcie go powodowało "pstryk" koniec zasilania ;)

Po kilku miesiącach wymiękłem wkurzało mnie X razy dziennie wpisywać wszystkie hasła...



Co do odczytania nazwy plików z bazy (m|s)locate to po samej nazwie wiele nie wywnioskujesz :) Co z tego że znajdziesz na liscie plik dupa.avi ? Może to filmik z imprezy gdzie ktoś się zalał w 3 dupy a "mili" koledzy to uwiecznili ? Albo co Ci o pliku powie nazwa P1235312312.orf ? Poza tym że MOŻE to być RAW z Olympusa ?

sj65 napisał(-a):

W laptopach  pamięci przechowują dane po wyłączeniu i te mogą być swobodnie odczytane, co do stacjonarnych nie wyobrażam sobie tej sytuacji.

"Stan wstrzymania: Ten tryb służy tylko do oszczędzania energii elektrycznej, jednak zasilanie nie zostaje odłączone całkowicie. Wiele podzespołów komputera, np. monitor i twardy dysk, zostaje wyłączonych. Nieprzerwany dopływ prądu pozwala zachować zawartość pamięci roboczej. Wystarczy nacisnąć dowolny klawisz, aby przywrócić tryb normalnej pracy systemu. Stan wstrzymania zaleca się stosować w krótkich przerwach pracy."

"Hibernacja: W tym trybie całkowita zawartość pamięci roboczej jest zapisywana w pliku Hiberfil.SYS na partycji systemowej (akurat na przykładzie windowsa), a następnie system zostaje zamknięty i komputer wyłączony. Taki sposób kończenia pracy ma pewną przewagę nad zwyczajnym wyłączaniem. Ponowne uruchomienie systemu trwa o połowę krócej, a ponadto zastaniesz system w dokładnie takim samym stanie, w jakim go opuściłeś. Wadą tego rozwiązania jest duża ilość wolnego miejsca na partycji systemowej, którą pochłania plik Hiberfil.SYS. Jego rozmiar odpowiada pojemności pamięci roboczej - w niektórych komputerach może więc zajmować nawet kilka gigabajtów."

W laptopie z reguły korzysta się z hibernacji. Nie wiem o co chodzi z tym czyszczeniem RAMu po wyłączeniu. Jeżeli odłączasz zasilanie od RAMu po minucie, z niego nie da się już żadnych danych odzyskać (możesz co prawda schłodzić ram i wtedy nawet dane będzie można, częściowo co prawda, odzyskać i po 5 czy 10 min). Czyszczenie pamięci jest pożądane podczas pracy systemu. Montujesz swój zaszyfrowany dysk, klucz i hasło wędruje do RAMu, odmontowujesz, dalej dane zostają w RAMie (póki nie zostaną nadpisane, tak jak na dysku). Wtedy przydaje się programik, który te dane nadpisze.

To tyle teorii.

Z Bleachbit korzystam, jednak nie popieram korzystania z systemu w celach "niewiadomych" a po tym wszystkim jego czyszczenia. Jeżeli nie chcesz w swoim systemie zostawić śladów, to dopalasz wirtualną maszynę i w niej operujesz. Masz pewność, że wszystkie operacje będą wykonane tylko wewnątrz tej wirtualnej maszyny. Gdy już skończysz przeglądać swoje strony porno i będziesz chciał być znów "dobrym człowiekiem" nadpisujesz obraz maszyny wirtualnej losowymi danymi. Z doświadczenia wiem, że zawsze się coś przeoczy w "czyszczeniu".

winnetou napisał(-a):

każde szyfrowane innym hasłem do tego pass na bios i bootloader :)

Nie wiem po co stosowałeś różne hasła dla różnych woluminów. Jeżeli ktoś w jakiś sposób by uzyskał twoje jedno hasło, to również uzyska pozostałe (inaczej by nie uzyskał tego pierwszego). Dla mnie lepszym rozwiązaniem jest stosowanie jednego dłuższego hasła do wszystkich woluminów (obejście bruteforce i szczęśliwego trafu) i patrzenie czy czasem nikt nie podpiął ci pod klawiaturę keylogera sprzętowego, albo nie podmienił klawiatury. Samo zakładanie haseł na bootloader i bios jest pozbawione sensu. Jeżeli ktoś ma fizyczny dostęp do twojej maszyny może zrobić z nią co mu się podoba.

winnetou napisał(-a):

Co do odczytania nazwy plików z bazy (m|s)locate to po samej nazwie wiele nie wywnioskujesz

A jeżeli ktoś będzie miał w nazwach plików frazy gay, anal, sex to też nic nie wywnioskujesz :D?

Jacekalex napisał(-a):

Do tego swapa moze nie być - ja przy 4GB ramu nie widze żadnej różnicy między swapem a brakiem swapa (tmp, /var/tmp i /var/run w ramie).

To zależy jak wykorzystujesz RAM. Ja np. mam 1GB ramu, mam SWAP 1,5GB i zwykle mam w RAMie 800-900MB a w SWAPie 300-1100. Jeżeli ty masz 4GB a używasz z tego w porywach ze 3-3,5GB to jasne że SWAP nie wpłynie na prace twojego systemu i możesz go zwyczajnie wyłączyć/wyrzucić.

Czemu nie powinna? Ty masz filmy, mp3 nazwane 001, 002, 003?

winnetou napisał(-a):

Ustawię sobie w aparacie żeby pliki nazyzwał: "priest_child_sexX " i co posądzisz mnie na podstawie nazwy pliku o pedofilię albo bycie księdzem lubującym się w młodych chłopcach?

Uwierz mi, gdybym podesłał zgłoszenie na policję, a oni by znaleźli same nazwy plików, byś miał kłopoty :D

Oczywistym jest, że to nie daje pełnego obrazu co trzymasz na dysku, jednak może wskazać co mniej więcej tam trzymasz. Pamiętaj żyjemy w Polsce, a tu nie ma domniemania niewinności i to ty musisz udowodnić, że tam pod nazwami owych plików nie kryją się materiały pedofilskie i jeżeli tego nie potrafisz to masz problem :]

Poza tym, zawsze możesz usunąć dziennik z ext3 i przejść na ext2. Ale w przypadku niekontrolowanego zamknięcia systemu, będą ci się uszkadzać pliki. Ale myślę, że dobry ups powinien rozwiązać ten problem.

Osobiście posiadam mnóstwo plików i katalogów z przypadkowymi rzeczami o nazwie dupa...

co nie oznacza że nie ma domniemania niewinności ;] Prawo mówi jasno a to, że życie pokazuje inaczej to już insz inszość. To dokładnie tak jak z teorią i praktyką:

TEORIA jest wtedy gdy wszystko wiemy i nic nie działa
PRAKTYKA jest wtedy gdy wszysko działa a my nie wiemy dlaczego
Tutaj łączymy teorię z praktyką czyli nic nie działa i nikt nie wie dlaczego

Na temat konfliktu z prawem się nie wypowiem ;))

Co do mniejszej bądź większej jasności prawa to akurat ten przepis jest jasny jak słońce - ale nie ma co dyskutować bo zawsze wygra (w sądzie) ten który będzie miał lepszego prawnika/szybciej przekupi sędziego ;]

Jestem właśnie w trakcie testowania programów z pakietu secure-delete, a konkretnie rozbawił mnie sdmem. Program z opisu w manie ma działać na takiej zasadzie jak powiedział sj65, czyli ma usunąć dane z pamięci RAM, bo jak się kompa wyłączy to dane dalej zostają w RAMie :D. W sumie to nie miałem pomysłu jak ten program ma zamiar to zrobić ale poszedłem o zakład, że komputer musi się powiesić, a zużycie RAMu sięgnąć 100%.

Czyszczenie trwało chyba z 5-7 min. W tym czasie faktycznie RAM zaczął się zapełniać losowymi danymi. Problem w tym, że tylko wolna przestrzeń a nie zajęta. Ale nic straconego, dalej komputer może się przecież powiesić. Obserwuję cyferki 65, 70%, 80... mówię sobie, trza było chociaż odmontować partycje truecrypta :] Po chwili widzę, że pasek ze swapem zaczyna się zapełniać. WTF miało przecie mi RAM czyścić, od swapu jest inny program. No nic, zapełnia ten SWAP powoli Zużycie RAMu pochodzi pod 90%, SWAP ma 99% i już słyszę te czkawkę w głośnikach i ... widzę na ekranie "Unicestwiony".

Podsumowując - RAMu niezapełnionego zostało 10%. Po unicestwieniu się programu, zostało w RAMie 151mb (z 600mb obecnych przed "czyszczeniem"), pozostałe zrzucone do SWAPu. Na moje oko, 151mb danych, które nie zostały "wyczyszczone" to jest bardzo dużo :D Trzeba by poddać analizie, to co zostało w RAMie . Dla mnie jednak, to jest nie do zaakceptowania, z punktu widzenia bezpieczeństwa.

Eksperyment wykazał, że przynajmniej tym programem, nie ma się w ogóle co interesować. Dziwię się, że nikt go jeszcze z tego pakietu nie wyrzucił.

Dziękuję za rzeczowe odpowiedzi.
Kwestia LVM została wyjaśniona w wystarczającym stopniu.
Resztę doczytałem.

Wątek rozszerzył się o dodatkowe zagadnienia związane z bezpieczeństwem o czym Koledzy wyżej nadmienili, ale pozwolę zadać jeszcze następujące pytania:

1. Co z dual-boot i instalacją dwóch lub więcej systemów? W jakiej kolejności tworzyć. instalować OS-y?
Przypadek
a) sda1 Windows XP ntfs zaszyfrowany TrueCrypt
    sda2 partycja na dane ntfs zaszyfrowana Truecrypt
    sda3 partycja /boot
    sda4 LVM ze swoimi logicznymi woluminami na których jest jeden linux z partycją /root oraz /home
Przypadek
b) sda1 partycja ext(? 2, czy 3) /boot
    sda2 Windows XP ntfs zaszyfrowany TrueCrypt
    sda3 partycja na dane ntfs zaszyfrowana Truecrypt
    sda3 LVM ze swoimi logicznymi woluminami na których jest jeden linux z partycją /root oraz /home

Moje pytanie związene jest z tym że TrueCrypt wpisuje się w MBR. Jak to później jest gdy aktualizujemy Linuksa a szczególnie jego jądro.

2. Czy lepiej instalować:
a) GRUB
b) GRUB2
Przy partycjach ext4 to pewno tylko GRUB2
c) czy lepiej najpierw szyfrować TrueCryptem Windows a następnie dopiero instalować na LVM Linuksa chodzi mi o nadpisywanie MBR ich bootloaderami?

3.)Czy przy układzie jak w pkt1 można korzystać z bootowania poprzez klucz na pendrive. Byłoby to wygodne rozwiązanie.

W ramach dygresji:
Przygotowywałem laptopa do instalacji.
Usunąłem partycje a następnie aby dysk wyczyścić włączyłem dbana z algorytmem o trzech przebiegach, a następnie jeszcze dysk wyzerowałem i przystąpiłem do instalacji systemu WInXP.
Ogromnie się zdziwiłem ale system nie wołał o serial, aktywacje itp po prostu zainstalował się.
Partycji recovery nie posiadam bo ją już dawno usunąłem.
Myślę że w laptopach na dyskach tworzone są ukryte miejsca (partycje?) nieusuwalne normalnymi metodami gdzie różne poufne dane takie jak serial są tworzone i przechowywane, a może to tylko przez to, że nie wyjąłem baterii i dane te instalator odczytał z RAM-u?
To tak ku rozwadze...

Pozdrowienia

Nie miałem ostatnio czasu na przeglądanie netu, jednak dziś trochę poszukałem o obejściu truecryptowego bootloadera. Poniżej linki:

http://niebezpiecznik.pl/post/jak-zlamac-haslo-do-bitlockera/
http://theinvisiblethings.blogspot.com/2009/10/evil … ruecrypt.html

Przy czym są to artykuły z końca 2009 roku. Nie wiem czy coś się w tej sprawie zmieniło. W tej chwili  nie mam za bardzo czasu by sobie zainstalować windowsa i przeprowadzić test. Może wieczorem, ew. jutro.

EDIT:

Bootloader truecrypta 7.1 nadal niezabezpieczony :] Bez problemu można odzyskać hasło.

Ostatnio edytowany przez morfik (2011-09-28 23:13:32)