Existe um sistema de arquivos criptografado somente para gravação para Linux?


14

Estou procurando por um sistema de arquivos criptografado para Linux que possa ser montado no modo somente gravação, ou seja, você poderá montá-lo sem fornecer uma senha, mas ainda poderá gravar / anexar arquivos, mas também não poder ler os arquivos que você escreveu, nem os arquivos que já estão no sistema de arquivos. O acesso aos arquivos só deve ser dado quando o sistema de arquivos é montado via senha. O objetivo disso é gravar arquivos de log ou dados semelhantes que são gravados apenas, mas nunca modificados, sem que os arquivos sejam expostos. As permissões de arquivo não ajudam aqui, pois quero que os dados estejam inacessíveis, mesmo quando o sistema estiver totalmente comprometido.

Existe algo assim no Linux? Ou, se não, qual seria a melhor alternativa para criar arquivos de log criptografados?

Minha solução atual consiste em simplesmente transmitir os dados gpg --encrypt, o que funciona, mas é muito complicado, como você não pode acessar facilmente o sistema de arquivos como um todo, é necessário canalizar cada arquivo gpg --decryptmanualmente.


3
Eu acredito que você pode fazer o que quiser via syslog. Isso separa a geração das mensagens de log do sistema que as armazena, para que os aplicativos que geram a mensagem não tenham acesso ao local onde estão armazenados. Os logs podem até estar (e frequentemente estão) em um servidor separado.
usar o seguinte comando

Quero dar um passo adiante e deixar os dados inacessíveis, não apenas para o processo que os criou, mas nem para fazer raiz. É o que a criptografia de chave pública com o gpg faz, mas estou procurando uma maneira de fazer isso no nível do sistema de arquivos.
Grumbel

Respostas:


4

... Quero que os dados estejam inacessíveis, mesmo quando o sistema estiver totalmente comprometido.

Isso não é possível. Se o sistema estiver totalmente comprometido, "por definição" qualquer coisa nele estará acessível - incluindo chaves de criptografia.

A criptografia é inútil para proteger contra comprometimentos do sistema, enquanto o sistema está em execução, SE as chaves para criptografar / descriptografar dados estiverem no mesmo sistema que os dados criptografados. Por exemplo, se você possui um sistema de arquivos LUKS montado e alguém obtém acesso root ao seu sistema, é possível extrair as chaves da RAM - porque elas precisam viver na RAM para descriptografar o sistema de arquivos. Na sua situação, se você estiver digitando sua senha sempre que criptografar um arquivo, estará protegido (assumindo que um keylogger não esteja presente no seu sistema); caso contrário, você estará na mesma situação e alguém que comprometa seu sistema poderá descobrir que chave e desfazer toda a sua criptografia.

Você precisa enviar os dados que deseja proteger para fora do sistema + NÃO gravá-los em uma mídia intermediária nesse sistema, se você absolutamente não deseja que o root os acesse. rsyslogexplicitamente oferece suporte a isso em relação ao log e é possível criptografar a conexão entre a origem e o coletor com o OpenVPN stunnel, ou similar. Tenho certeza de que existem outras opções de transferência "unidirecionais" por aí.



"porque eles precisam viver na RAM para descriptografar o sistema de arquivos" isso pode ser verdade com o LUKS especificamente, mas não em geral: a criptografia assimétrica é projetada exatamente para esse fim (alguém segurando a chave pública pode criptografar, mas não descriptografar)
Clément

3

Parece-me que você está indo na direção errada. Se você quiser um arquivo no qual possa gravar, mas não possa ler, é o que procura.


$ touch log
$ chmod 222 log
$ echo test > log
$ cat log
cat: log: Permission denied

Obviamente, esse arquivo pode estar em um sistema de arquivos criptografado.


Você pode montar o sistema de arquivos com uma determinada umask, não permitindo que os usuários alterem as permissões.
Nos

E apenas o proprietário do arquivo (ou superusuário) pode alterar a permissão.
gorila

Eu acho que o OP está tentando se proteger mesmo contra um invasor se enraizando.
Clément

1
umask 0477 && touch file && echo test > file && cat file

também pode ser útil. Qualquer arquivo criado no processo atual terá o modo 0200.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.