Ocultando uma pasta criptografada em um sistema compartilhado sem acesso root (unshare -m)

2

Sou um estudante de pós-graduação tentando usar um cluster na minha universidade. Essas máquinas são compartilhadas, então eu quero proteger o código-fonte que eu uso (eu assinei um NDA, então estou com medo de publicar o código por acidente ou torná-lo público com muita facilidade). Até agora, consegui colocar meu código-fonte em um ecryptfs. Para desativar o acesso de outros usuários, eu uso:

unshare -m /bin/bash 

e depois:

mount -n -t ecryptfs ~home/crypt ~home/crypt

Isso funciona muito bem na minha estação de trabalho, criptografando a pasta ~ home / crypt apenas na sessão atual. Mesmo o mesmo usuário não pode acessar os arquivos criptografados sem montá-lo novamente. O problema que tenho é que eu preciso ser um sudoer para executar esses comandos.

O administrador do cluster deu acesso a:

sudo mount -n -t ecryptfs ~/crypt ~/crypt

Mas,

sudo unshare -m /bin/bash

me daria um shell de root e este é um show stopper.

Existe outra solução para isso? Uma configuração de sudoers pode resolver esse tipo de problema?

Estou compilando um sistema C ++ usando algumas bibliotecas externas. Até agora, estou construindo uma VM para compilar meu código com as mesmas bibliotecas usadas no Cluster (mesma distribuição Linux, etc). Mas esta solução não ficará bem por muito tempo, já que as atualizações do Cluster quebrariam meu próximo ciclo de criação / lançamento. Vou tentar liberar meu código no modo estático também, mas eu realmente não gosto dessa abordagem.

Estou usando uma máquina Linux CentOS 6.3 64 bits (Intel).

Os arquivos de origem são armazenados em um NAS (8TB) com acesso FTP e uma interface web muito fraca.

    
por nmenezes 16.12.2013 / 17:35

2 respostas

1

A criptografia é uma pista secreta aqui. Protege apenas contra um conjunto muito pequeno de ameaças.

O administrador do cluster pode ler todos os seus arquivos assim que você inserir a chave para descriptografá-los. A criptografia só protegeria você contra o administrador se você nunca descriptografasse os arquivos no cluster, caso em que você poderia usar alguma forma offline de armazenamento criptografado como o PGP.

Outros usuários são restringidos por permissões de arquivo. Se os arquivos são armazenados criptografados ou não, isso é irrelevante; eles nem sabem disso, exceto por verificar a localização dos arquivos em relação aos pontos de montagem do sistema de arquivos criptografados - e, tecnicamente, eles não podem ter certeza se um sistema de arquivos FUSE armazenou seus dados de uma maneira criptografada.

A criptografia apenas protege contra alguém que acessaria o armazenamento enquanto ele é desmontado, especialmente backups feitos sem acessar o ponto de montagem do ecryptfs. Esta é uma ameaça muito limitada. Seu laptop (se você tiver um e armazenar esses arquivos nele) é mais um risco

A menos que você tenha instruções explícitas para proteger contra essas ameaças raras, não se preocupe com criptografia: é a ferramenta errada. O que você precisa, se você usa criptografia ou não, são permissões de arquivo adequadas.

Se você definir um diretório para ser legível somente por você ( chmod 700 /path/to/directory ou chmod u+rwx,go= /path/to/directory , exibido como drwx------ na saída ls -l ), outros usuários não poderão acessar nenhum arquivo desse diretório. A falta de x de permissão no diretório impede que eles acessem qualquer arquivo ou subdiretório nele.

    
por 17.12.2013 / 02:50
1

Em vez de usar sudo para conceder a possibilidade de usar unshare , você poderia usar o bit setuid, porque o programa unshare foi projetado para funcionar com ele. Diz na página man:

The unshare command drops potential privileges before executing the target program. This allows to setuid unshare.

Portanto, após executar sudo chmod u+s /usr/bin/unshare , a execução de unshare -m fornecerá a você um shell como seu próprio usuário, não como raiz.

Se apenas um grupo específico de usuários tiver a possibilidade de executar unshare , definir as permissões para algo como

-rwsr-x--- 1 root unshare 10432 Feb 12 19:53 /usr/bin/unshare

Agora, apenas os usuários do grupo unshare poderão executá-lo. Note que você não pode restringir valores de parâmetros como você pode com sudo .

    
por 28.07.2015 / 13:04