난 방금 읽었어이 토론리누스 토발즈(Linus Torvalds)와 (다른 사람들 사이에서)밀란 브로즈, dm-crypt의 관리자 중 한 명입니다.
나는 토론의 다음 부분에 관심이 있습니다.
리누스 토발즈: 숨겨진("거부할 수 있는") 것을 사용하는 사람들은 실제로는 절대 사용하지 않는 것 같습니다.사용완전히 외부 파일 시스템이므로 실제 암호화된 내용을 거기에 넣을 수 있으므로 걱정할 필요가 없습니다.
Milan Broz: 글쎄요, 데이터가 "최신"으로 보이도록 때때로 외부를 "사용"해야 하며 전체 "숨겨진 OS"에 대해서는 요청 시 외부 미끼 OS로 부팅할 수도 있어야 합니다. , 뭔가가 바로 거기에서 작동한다는 것을 보여주기 위한 것입니다.
이론적으로 나는 미끼 데이터를 사용하는 것이 신뢰성을 높이는 데 좋은 것이라는 Milan의 의견에 동의합니다. 그러나 이것이 실제로 어떻게 달성됩니까? 예를 들어 내부 볼륨을 덮어쓸 위험 없이 외부 볼륨에 쓸 수 있는 방법은 무엇입니까?
저는 분리 가능한 헤더 및 데이터 오프셋과 결합된 숨겨진 LUKS 볼륨을 수년 동안 사용해 왔습니다. 일반적으로 작은 LUKS 암호화 외부 볼륨(예: 20GB)을 생성하고 EXT4로 포맷하고 미끼 데이터로 채운 다음 해당 외부 볼륨의 크기(예: 500GB)를 늘린 다음 내부 볼륨을 만듭니다. 25GB입니다.
그 후 저는 Linus가 말한 대로 하고 내부 볼륨의 데이터가 손상될까 봐 외부 볼륨의 미끼 데이터를 만지는 것을 종교적으로 피했습니다.
내부 볼륨의 데이터가 손상될 위험 없이 외부 볼륨의 데이터를 새로 고칠 수 있는 방법이 있습니까? 예를 들어, 롤아웃의 처음 20개 쇼에 구체적으로 기록하여 다음 480개 쇼가 엉망이 되지 않도록 할 수 있는 도구가 있습니까?
저는 HDD와 SSD를 모두 사용하므로 이 질문은 둘 다에 적용됩니다.
답변1
이를 안전하게 수행하는 방법에는 여러 가지가 있을 수 있으며, 새 외부 볼륨이나 기존 외부 볼륨에서 시작하는 경우 접근 방식도 다를 수 있습니다.
아마도 가장 좋은 접근 방식은 debugfs setb외부 파일 시스템을 마운트하고 그 안의 파일을 업데이트하기 전에 마운트 해제된 외부 파일 시스템 장치에서 명령을 사용하여 내부 볼륨에 속하는 블록 범위를 표시하는 것입니다.
debugfs -c -R "setb <inner_start_blk> <inner_count>" /dev/<outer>
setb block [count]
Mark the block number block as allocated. If the optional argument
"count" is present, then "count" blocks starting at block number
"block" will be marked as allocated.
파일에 분리된 범위가 있는 경우 다음과 같이 블록 범위를 사용하여 파일을 파이핑하여 여러 setb 명령을 스크립팅할 수 있습니다.
setb <range1> <count1>
setb <range2> <count2>
:
debugfs파일을 읽으 려면 debugfs -c -f <file> /dev/<outer>.
외부 파일 시스템의 끝 부분에 내부 볼륨을 압축하는 것뿐만 아니라 좀 더 똑똑해지고 싶다면 처음에 fallocate -s 32M mydir/inner외부 파일 시스템에 내부 볼륨을 생성한 후 다음에서 블록 범위를 생성할 수 있습니다 debugfs.
# debugfs -c -R "stat mydir/inner" /dev/vg_root/lvhome
Inode: 263236 Type: regular Mode: 0664 Flags: 0x80000
Generation: 2399864846 Version: 0x00000000:00000001
User: 1000 Group: 1000 Project: 0 Size: 32499577
File ACL: 0
Links: 1 Blockcount: 63480
Fragment: Address: 0 Number: 0 Size: 0
ctime: 0x63c98fc0:62bb0a38 -- Thu Jan 19 11:45:20 2023
atime: 0x63cee835:5e019630 -- Mon Jan 23 13:04:05 2023
mtime: 0x63c98fc0:559e2928 -- Thu Jan 19 11:45:20 2023
crtime: 0x63c98fc0:41974a6c -- Thu Jan 19 11:45:20 2023
Size of extra inode fields: 32
Extended attributes:
security.selinux (37) = "unconfined_u:object_r:user_home_t:s0\000"
EXTENTS:
(0-7934):966656-974590
이 예에서 ~32MB(7935x4KiB 블록) 파일은 블록 966656-974590에 있으므로 setb 966656 7935해당 블록을 사용된 것으로 표시하는 데 사용됩니다. clri <inum>할당된 블록 범위가 나중에 표시되지 않도록 하려면 inode를 지워야 합니다 .
외부 파일 시스템에 할당된 블록은 debugfs setb다음에 e2fsck가 외부 파일 시스템에서 실행될 때까지 할당된 상태로 유지됩니다. 누군가 이렇게 하면 사용 중인 블록이 "노출"될 수 있습니다.진짜따라서 외부 파일 시스템을 마운트 해제한 후 `debugfs -c -R "clrb <inner_start> <inner_count>" /dev/"를 사용하여 외부 파일 시스템을 다시 지우거나 할당을 보존하여 가능한 손상을 방지하는 옵션이 있습니다. 내부 파일 시스템.
답변2
나는 정당한 거부를 직접 사용하지 않으므로 이것을 의견으로 처리하십시오.
당신이 사용할 수있는장치 매퍼작업( dmsetup).
선형 매핑(실제 데이터에 매핑된 섹터 범위), 오류 매핑(존재하지 않고 읽기/쓰기 오류만 생성하는 섹터 범위), 제로 매핑(쓰기를 삭제하고 읽기 시 0을 반환하는 섹터 범위) 영역 범위를 설정할 수 있습니다. )), 스냅샷(기록 중 복사 덮어쓰기),...
따라서 외부 볼륨 영역만 표시되고, 내부 볼륨은 보호되며, 내부 볼륨에 대한 쓰기는 효과적으로 삭제되거나 스냅샷 영역에 일시적으로만 저장되는 블록 장치를 설계할 수 있습니다. 그리고 이러한 영역을 읽으려고 하면 0이 생성되거나 읽기 오류가 발생할 수 있습니다.
해당 외부 볼륨에 가상 머신을 설치하거나 시작할 수도 있으며, 내부 볼륨을 손상시키거나 액세스할 수 없습니다. 그러나 이러한 보호 계층 없이 사용할 경우 그러한 약속은 없습니다.
또 다른 옵션은 외부 볼륨에 파일을 생성하여 공간을 할당한 다음 dm-linear를 사용하여 할당된 파일 공간에서 사용 가능한 블록 장치를 생성하는 것입니다( filefrag각 파일에 할당된 섹터 범위가 표시됨). 이렇게 하면 외부 파일 시스템의 파일이 내부 볼륨을 보호합니다.
이 접근 방식을 사용하면 외부 파일 시스템을 자유롭게 사용할 수 있으며 해당 시스템에서 TRIM/폐기를 실행할 수도 있습니다. 내부 볼륨을 나타내는 파일이 변경되지 않은 한 모든 것이 정상입니다. 이는 또한 외부 볼륨 파일 시스템이 자체적으로 파일 내용을 재배치/다시 쓰지 않는다는 것을 가정합니다(조각 모음, 재압축, 중복 제거 등 없음).