Montagem permanente / desmontagem em cada execução

1

Estamos implementando um serviço que precisa de acesso a três discos que residem em servidores diferentes . Eu montei os discos (2 estão nos servidores de arquivos do Windows, cifs; 1 está em outro servidor Linux, nfs) e os scripts agora funcionam bem.

Meu gerente não está muito satisfeito com a "montagem permanente" e considera isso um risco de segurança: se qualquer script no servidor for comprometido, os discos montados poderão ser acessados. Ele sugere que cada script que precisa dos discos, monta os discos no início do script e osounts no final do script .

Não gosto muito dessa ideia, mas não posso convencê-lo. Alguns argumentos que tentei:

  • mount e umount têm um custo - fazer isso toda vez fará com que os scripts rodem mais devagar. (infelizmente, não consigo identificar o custo exato)
  • E se dois scripts forem executados simultaneamente, um terminar e um, e o outro ainda precisar dos discos? (concedido, semáforos ou mutexes poderia resolver isso)
  • Se alguém comprometer o servidor, ele poderá acessar o script que monta o disco e montá-lo também. (Ele alega que esta é uma 'camada extra de defesa para violar').

Alguém pode me dizer se estou certo em ter cuidado com essa montagem / desmontagem de cada vez, ou se estou errado e é realmente o caminho a seguir - e, mais especificamente: por quê?

    
por Konerak 15.03.2011 / 10:10

2 respostas

1

Desculpe, mas você não está certo.

  1. O custo de montagem e desmontagem não é tão grande. Como é que os discos são montados / desmontados?
  2. Use um arquivo de bloqueio e deixe a montagem / umount ser executada apenas uma vez por vez.
  3. Se é o meu servidor, você não pode saber o que estou fazendo lá, e você não pode saber nada sobre meus scripts. Então é melhor ter os discos desmontados.

Atenciosamente

    
por 15.03.2011 / 10:22
1

A automontagem de compartilhamentos de rede significa armazenar credenciais em um arquivo em algum lugar onde mount possa lê-las (via a opção credentials=filename mount no caso de sistemas de arquivos cifs) - isso não é necessariamente um problema, mas pode ser uma preocupação de segurança uma exploração que dá a alguém acesso ao script. Armazenar as credenciais em um arquivo como este é mais seguro do que mantê-las no script diretamente, pois dessa forma não há chance de elas aparecerem nas linhas de comando quando os usuários pesquisarem a lista de tarefas com ps ou similar, mas é de vital importância Certifique-se de que apenas o script possa ler o arquivo. Sua preocupação com os usuários que comprometem o servidor não é diferente nesta situação - se eles o comprometerem enquanto estiver ativo, eles potencialmente terão acesso aos compartilhamentos de qualquer maneira.

O custo de montar e desmontar compartilhamentos não deve ser significativo - alguns segundos (no máximo), a menos que você esteja falando com os compartilhamentos em uma conexão muito lenta de alta latência, e pode ser preferível do ponto de vista de segurança. você não está mantendo o compartilhamento montado (potencialmente de uma maneira que possa deixá-lo legível a outros usuários com acesso) quando não for necessário e a outra extremidade poderá registrar quando seus scripts autenticarem e desconectarem (portanto, se houver um problema detectado no outro extremo, é mais fácil rastrear o que pode ter tido acesso no momento em que o problema parece ter ocorrido).

Manter os compartilhamentos montados, apesar das execuções de scripts sobrepostas, poderia ser feito descartando um arquivo com um nome aleatório (ou de outra forma suficientemente improvável para ser duplicado por outra chamada de script) em algum local (por exemplo, um diretório em /var/run ) e excluindo depois que o trabalho real do script terminar - do que no final, verifique se não há outros arquivos nesse diretório antes de executar umount . Outro método seria permitir várias montagens para o mesmo compartilhamento, atribuindo a cada script seu próprio ponto de montagem - assim, cada script teria seu próprio compartilhamento e não interferiria com os outros, além de poder fornecer a cada script suas próprias credenciais de autenticação. você tem a opção de gerenciar permissões de uma maneira mais refinada no outro lado (talvez alguns dos scripts precisem de acesso de leitura + gravação e alguns precisem apenas de leitura, por exemplo).

    
por 15.03.2011 / 11:00