Czasami trzeba usunąć plik w systemie plików i upewnić się, że plik naprawdę zniknął. Na przykład plik zawierający wrażliwe hasła powinien zostać dokładnie wyczyszczony z dysku.
Wydanie prostego rmw typowym systemie plików usuwa i-węzeł („wskaźnik”) do pliku, ale nie usuwa zawartości pliku na dysku fizycznym - są one tam, dopóki nie zostaną zastąpione, gdy system plików potrzebuje wolnego miejsca.
W wielu systemach plików program niszczenia umożliwia takie bezpieczne usuwanie. Jednak w systemie plików CoW, takim jak btrfs, takie podejście jest bezużyteczne . Problem pogarsza fakt, że plik może być obecny na migawkach woluminów.
Czy istnieje sposób na bezpieczne usunięcie pliku w systemie plików btrfs? Czy wystarczy usunąć wszystkie wskaźniki (na wszystkich woluminach) i wypełnić wolne miejsce zerami ?
źródło
Odpowiedzi:
Bezpieczne usuwanie to trudna propozycja dla dowolnego systemu plików. O ile system plików nie jest bardzo specyficzny i nie gwarantuje, że nie ma innych kopii pliku, musisz wyczyścić całe wolne miejsce na urządzeniu. Podczas gdy istnieje większe prawdopodobieństwo, że znajdziesz wiele bitów pliku w systemach plików kopiowania przy zapisie, nawet bardziej „statyczne” systemy plików nie mają tej gwarancji w praktyce, ponieważ wiele plików jest edytowanych, więc jest trochę z poprzednich wersji leżący plik.
Zauważ, że kasowanie zerami jest tak samo dobre jak kasowanie losowych bajtów i nie potrzebujesz wielu przejść. Kasowanie zerami pozostawia resztkowe dane, które można częściowo odzyskać w warunkach laboratoryjnych za pomocą technologii dysków twardych z lat osiemdziesiątych; obecnie nie ma to zastosowania. Zobacz, dlaczego wielokrotne pisanie zer (lub danych losowych) na dysku twardym jest lepsze niż jednorazowe zrobienie tego?
Możesz pozbyć się poufnych danych w postaci jawnego tekstu, szyfrując wszystko na dysku. Skonfiguruj wolumin ecryptfs w tym systemie plików i przenieś do niego wszystkie (poufne) pliki. Następnie zastąp całą nieużywaną przestrzeń systemu plików. Możesz usunąć większość z nich, wypełniając system plików
cat /dev/zero >zero. W niekompletnych blokach mogą pozostać pewne informacje (bloki zawierające ostatnią część pliku, a następnie śmieci) - które mogą pozostać z poufnego pliku). Aby upewnić się, że nie ma niekompletnych bloków, przenieś wszystko w systemie plików do ecryptfs (pliki ecryptfs używają całych bloków, przynajmniej w typowych konfiguracjach, w których bloki mają rozmiar 4kB). Pamiętaj, aby zastosować to do wszystkich woluminów i usunąć wszystkie migawki zawierające poufne dane w postaci zwykłego tekstu.W czasopiśmie mogą pozostać pewne informacje. Nie wiem jak to wyszorować.
Na dysku SSD ze względu na realokację bloku mogą pozostać dane, których nie można odczytać zwykłymi programami, ale można je odzyskać poprzez zhakowanie oprogramowania układowego lub dostęp fizyczny. Tam jedynym wyjściem jest pełne wyczyszczenie dysku SSD.
źródło
0byłoby w porządku i nie podlegało TRIMingowi, powiedzmy, że piszemy wszystko1? A może niektóre dyski używają kompresji na wszystkim?Hmmm, btrfs wydaje się pokonać wszystkie zwykłe metody niszczenia ...
nodatacowale wydaje się, że nie wpływa to na już istniejące pliki.debugfs. Dotyczy tylko systemów plików ext, ale istnieje łatka , która może działać. Możesz go użyć, aby znaleźć adresy bloków, których dotyczy problem, a następnie zastąpić je bezpośrednio na / dev / sdXY. Jest to jednak bardzo niebezpieczne i może nie działać (zwłaszcza jeśli jest więcej migawek pliku)Najczystszą próbą (w przypadku naprawdę bardzo wrażliwych danych) byłoby:
To może nie być najtańsze podejście, ale biorąc pod uwagę dzisiejsze niskie koszty przechowywania i kłopoty z innymi opcjami, może to być najtańsze (pod względem godzin pracy).
źródło
nodatacowustawia domyślny statusCflagi dla nowo tworzonych plików. Z pewnością możnachattr +C ~/.browser/logins.sqlitetoshredzrobić?Jest
shred(1)dla Uniksa / Linuksa (powinien znajdować się w paczkach twojej dystrybucji). To właśnie poleca EFF .źródło