btrfs 파일 시스템에서 파일을 안전하게 삭제

22

때로는 파일 시스템에서 파일을 삭제하고 파일이 실제로 없어 졌는지 확인해야합니다. 예를 들어 민감한 암호가 포함 된 파일은 디스크에서 완전히 정리해야합니다.

rm일반적인 파일 시스템 에서 단순 을 실행하면 파일에 대한 inode ( "포인터")가 삭제 되지만 물리 디스크의 파일 내용은 삭제되지 않습니다 . 파일 시스템에 여유 공간이 필요할 때 덮어 쓰기 전까지는 그대로 유지됩니다.

많은 파일 시스템에서 파쇄 프로그램 은 이러한 안전한 삭제를 가능하게합니다. 그러나 btrfs와 같은 CoW 파일 시스템 에서이 방법은 쓸모가 없습니다 . 파일이 볼륨 스냅 샷에있을 수 있기 때문에 문제가 더욱 악화됩니다.

btrfs 파일 시스템 에서 파일 을 안전하게 삭제하는 방법이 있습니까? 모든 포인터에서 모든 포인터를 삭제 하고 여유 공간을 0으로 채우면 충분 합니까?

— 고 칼로프
소스

2

좋은 질문입니다, 나는 전에 그 문제를 생각하지 못했습니다. 이 문제를 해결하는 한 가지 방법은 해당 파일을 암호화하는 것입니다. 전체 디스크를 암호화 할 수도 있지만 공격자가 실행중인 시스템에 대한 루트 액세스 권한을 얻는 경우 도움이되지 않습니다.

— mreithub

@mreithub 실제로 이러한 파일을 암호화하는 것은 FDE와 마찬가지로 항상 좋은 아이디어입니다. 그래도 모든 유스 케이스를 고려할 수는 없습니다 (예를 들어 임베디드 시스템-그러한 시스템이 btrfs를 실행 중이라면 논쟁의 여지가 있습니다 ...). 나는 중요한 파일을 복사하기 전에 설치 암호를 잊어 버려 사실이 부탁 해요,하지만 난 모든 파티션을 닦아 않도록하고 싶습니다

— goncalopp

9

안전한 삭제는 모든 파일 시스템에서 어려운 제안입니다. 파일 시스템이 매우 독특하고 다른 파일 사본이없는 것을 보장하지 않는 한 장치의 모든 여유 공간을 비워야합니다. COW (Copy-On-Write) 파일 시스템에서 파일의 많은 비트를 찾을 가능성이 높지만, 더 많은 "정적"파일 시스템은 실제로는 많은 파일이 편집되므로 이전 버전의 비트가 있기 때문에 실제로 이러한 보장이 없습니다 거짓말하는 파일.

0으로 지우는 것은 임의의 바이트로 지우는 것만 큼 좋으며 여러 번 통과 할 필요가 없습니다. 1980 년대의 하드 디스크 기술로 실험실 조건에서 부분적으로 복구 할 수있는 잔여 데이터가 0으로 지워졌습니다. 오늘날에는 더 이상 적용 할 수 없습니다. 하드 드라이브에 0 (또는 임의의 데이터)을 한 번만 쓰는 것보다 여러 번 쓰는 것이 더 좋은 이유는 무엇입니까?를 참조하십시오 .

디스크의 모든 내용을 암호화하여 일반 텍스트 기밀 데이터를 제거 할 수 있습니다. 해당 파일 시스템에 ecryptfs 볼륨을 설정하고 모든 (기밀) 파일을 여기로 옮깁니다. 그런 다음 파일 시스템의 사용되지 않은 공간을 모두 덮어 씁니다. 파일 시스템을로 채워서 대부분을 지울 수 있습니다 cat /dev/zero >zero. 불완전한 블록 (파일의 마지막 청크를 포함하는 블록과 일부 가비지-기밀 파일에서 남을 수있는 블록)에 여전히 일부 정보가 남아있을 수 있습니다. 불완전한 블록이 없는지 확인하려면 파일 시스템의 모든 항목을 ecryptfs로 이동하십시오 (ecryptfs의 파일은 블록이 4kB 인 일반 설정에서 전체 블록을 사용함). 이것을 모든 볼륨에 적용하고 평문 기밀 데이터가 포함 된 모든 스냅 샷을 지우십시오.

여전히 저널에 일부 정보가 남아있을 수 있습니다. 나는 그것을 문지르는 방법을 모른다.

SSD에서 블록 재 할당으로 인해 정상적인 소프트웨어 수단으로는 읽을 수 없지만 펌웨어를 해킹하거나 물리적 액세스를 통해 복구 할 수있는 데이터가 남아있을 수 있습니다. 유일한 해결책은 SSD를 완전히 닦는 것입니다.

— 질 'SO- 악마 그만해'
소스

3

0은 압축되거나 완전히 생략 될 수 있다는 단점이 있습니다 (TRIM의 섹터를 읽을 때 0을 리턴하므로 SSD는 0을 작성하는 대신 TRIM 할 수 있음). 오늘날에는 제로가 안전하지 않습니다. 무작위 데이터를 사용하면 파일 시스템과 디스크가 실제로 데이터를 그대로 쓸 수 있습니다.

— frostschutz

@frostschutz TRIMing의 0대상이 아닌 ok 이외의 문자 를 쓰려면 all 1대신 쓰는 것이 좋습니까? 아니면 일부 드라이브가 모든 것을 압축합니까?

— Xen2050

@frostschutz ecryptfs 볼륨을 0으로 채우는 경우 (여기에서 답변이 제안하는 것으로 생각하지만, 추가 검사에서 그의 문구가 실제로 모호하다는 것을 알 수 있습니다), 본질적으로 무작위로 작성됩니다 (압축 불가 / 디스크에 데이터를 넣을 수 없습니다)

— JamesTheAwesomeDude

@JamesTheAwesomeDude 아니요, 암호화되지 않은 부분에 0을 쓰는 것을 제안하고 있었지만 SSD 아래에서는 더 이상 충분하지 않다고 언급했습니다.

— Gilles 'SO- 악마 그만'

6

흠, btrfs는 모든 일반적인 파쇄 방법을 물리 치는 것 같습니다 ...

마운트 옵션이 nodatacow있지만 이미 존재하는 파일에는 영향을 미치지 않는 것 같습니다.
디스크에 적절한 파일이 이미 있으면이 btrfs FAQ 항목으로도 도움이되지 않습니다.
다음이 debugfs있습니다. ext 파일 시스템 전용이지만 작동 할 수 있는 패치 가 있습니다. 이를 사용하여 영향을받는 블록 주소를 찾은 다음 / dev / sdXY에서 직접 덮어 쓸 수 있습니다. 그러나 그것은 매우 위험하며 작동하지 않을 수 있습니다 (특히 파일의 스냅 샷이 더 많은 경우)
특정 스냅 샷 또는 전체 파일을 수정 (또는 파쇄) 할 수있는 btrfs 패치 작성
(정말로 민감한 데이터를위한) 가장 깨끗한 시도는 다음과 같습니다.
- 다른 디스크를 구입하십시오 (첫 번째 디스크에 영향을받는 파티션의 사본을위한 충분한 여유 공간이없는 경우)
- 전체 디스크 암호화 및 파일 시스템 설정
- 디스크 a에서 b로 모든 것을 복사
- 시스템 b로 부팅하고 전체 디스크 a를 파쇄합니다 ...
이것은 가장 저렴한 방법은 아니지만 오늘날의 낮은 스토리지 비용과 다른 옵션으로 인한 문제를 고려하면 실제로 가장 저렴한 방법 일 수 있습니다 (노동 시간 측면에서).

— mreithub
소스

nodatacow새로 작성된 파일 에 대한 C플래그 의 기본 상태를 설정 합니다. 분명히 하나는 수 다음 그것을? chattr +C ~/.browser/logins.sqliteshred

— JamesTheAwesomeDude

-6

이 shred(1)(배포판의 패키지에 있어야합니다) 유닉스 / 리눅스. 나는 EFF가 권장하는 것 입니다.

— 폰 브란트
소스

3

당신이 질문을 두 번 선택하면, 당신은 내가 분쇄기 언급 한 것을 볼 수 있습니다, 그리고 작업에 충분하지 않은 이유

— goncalopp

내가 찾은 모든 것은 당신이 언급 한 이유로 민감한 파일의 암호화를 사용하는 제안입니다.

— vonbrand 2016 년

2

"많은 파일 시스템에서 파쇄 프로그램은 이러한 안전한 삭제를 가능하게합니다. 그러나 btrfs와 같은 CoW 파일 시스템에서는이 방법이 쓸모가 없습니다." 거기에는 두 개의 링크가 있습니다.

— goncalopp