Início / unix / Perguntas / 740483
Accepted
ChennyStar
Asked: 2023-03-21 21:42:06 +0800 CST

Como atualizar dados de isca em um esquema dm-crypt de negação plausível?

  • 772

Acabei de ler esta discussão entre Linus Torvalds e (entre outros) Milan Broz , um dos mantenedores do dm-crypt.

Estou intrigado com a seguinte parte da discussão:

Linus Torvalds: Achei que as pessoas que usavam coisas ocultas ("negadas") na verdade nunca usavam o sistema de arquivos externo, exatamente para que pudessem colocar a coisa criptografada real lá e não se preocupar com isso.

Milan Broz: Bem, eles deveriam "usar" o exterior de vez em quando para que os dados pareçam "recentes" e para todo o "sistema operacional oculto" eles deveriam ser capazes de inicializar o sistema operacional chamariz externo mediante solicitação, apenas para mostrar que algo trabalhando está lá.

Em teoria, concordo com a afirmação de Milan, usar os dados do chamariz é uma boa coisa a se fazer para aumentar a credibilidade. Mas como conseguir isso na prática? Por exemplo, como você pode escrever no volume externo sem correr o risco de sobrescrever o volume interno?

Eu uso volumes LUKS ocultos há anos, combinando cabeçalhos destacáveis ​​e deslocamento de dados. Normalmente começo criando um pequeno volume externo criptografado com LUKS (digamos 20 GB), formato-o com EXT4, preencho-o com dados chamarizes, depois aumento o tamanho desse volume externo (para, por exemplo, 500 GB) e crio o volume interno com um deslocamento de 25 GB, por exemplo.

E depois disso faço o que Linus disse, evito religiosamente tocar nos dados chamariz do volume externo, com medo de danificar os dados do volume interno.

Existe uma maneira de atualizar os dados do volume externo, sem correr o risco de danificar os dados do volume interno? Por exemplo, existe uma ferramenta para escrever especificamente nos 20 primeiros shows do volume externo, certificando-se de não mexer nos 480 shows seguintes?

Estou usando HDDs e SSDs, então a questão se aplica a ambos.

partition

2 respostas

  1. Best Answer

    Provavelmente, existem algumas maneiras de fazer isso com segurança razoável, com abordagens potencialmente diferentes se começar com um novo volume externo ou existente.

    Provavelmente, a melhor maneira de fazer isso seria com o debugfs setbcomando no dispositivo do sistema de arquivos externo desmontado para marcar o(s) intervalo(s) de blocos que pertencem ao volume interno antes de montar o sistema de arquivos externo e atualizar os arquivos lá.:

    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.

    Se houver intervalos disjuntos no arquivo, vários comandos setb poderão ser gravados em script canalizando um arquivo com intervalos de bloco como:

    setb <range1> <count1>
setb <range2> <count2>
:

    para debugfsler o arquivo debugfs -c -f <file> /dev/<outer>.

    Se você quiser ser um pouco mais inteligente do que apenas empacotar o volume interno no final do sistema de arquivos externo, o volume interno pode ser inicialmente criado no fallocate -s 32M mydir/innersistema de arquivos externo, então o intervalo de blocos pode ser gerado a partir de 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

    Neste caso, o arquivo de ~32MB (bloco de 7935x4KiB) está nos blocos 966656-974590, portanto, isso seria usado setb 966656 7935para marcar esses blocos usados. O inode deve ser apagado com clri <inum>para evitar que o intervalo de bloco alocado fique visível posteriormente.

    Os blocos alocados no sistema de arquivos externo debugfs setbpermaneceriam alocados até a próxima vez que o e2fsck fosse executado no sistema de arquivos externo. Isso poderia potencialmente "expor" que esses blocos estão em uso se alguém estivesse realmente prestando atenção, então eles poderiam opcionalmente ser limpos novamente depois que o sistema de arquivos externo fosse desmontado, usando `debugfs -c -R "clrb <inner_start> <inner_count>" /dev /", ou mantido alocado para evitar que o sistema de arquivos interno seja potencialmente corrompido.

    • 1

  2. Eu mesmo não uso negação plausível, então considere isso um comentário.

    Você pode usar o mapeador de dispositivos para o trabalho ( dmsetup).

    Ele permite que você configure mapeamentos lineares (intervalos de setores que mapeiam para dados reais), mapeamentos de erros (intervalos de setores que não existem e simplesmente produzem erros de leitura/gravação), mapeamentos de zero (intervalos de setores que descartam gravações e retornam zeros nas leituras ), instantâneos (sobreposições copy-on-write), ...

    Assim, você pode criar um dispositivo de bloco onde apenas a área do volume externo é visível, o volume interno é protegido e as gravações no volume interno serão efetivamente descartadas ou armazenadas apenas temporariamente em uma área de instantâneo. E as tentativas de leitura nessas áreas podem resultar em zeros ou erros de leitura.

    Você poderia montar ou até mesmo ativar uma VM nesse volume externo e ela não teria como danificar ou acessar seu volume interno. No entanto, não há tais promessas ao usá-lo sem essa camada de proteção.

    Outra opção é alocar espaço criando arquivos no volume externo e, em seguida, usar o dm-linear para criar um dispositivo de bloco utilizável a partir desse espaço de arquivo alocado (mostrará os filefragintervalos de setor alocados para cada arquivo). Dessa forma, os arquivos do sistema de arquivos externo protegeriam o volume interno.

    Essa abordagem permitiria que você usasse o sistema de arquivos externo livremente e até mesmo executasse TRIM/discard nele. Qualquer coisa estaria bem, desde que os arquivos que representam o volume interno permaneçam intocados. Isso também pressupõe que o sistema de arquivos do volume externo não irá realocar/reescrever o conteúdo do arquivo por conta própria (sem desfragmentação, recompactação, descompactação, ...).

    • 0

relate perguntas