Privado encfs mount (acesso limitado por processo)

2

Como restringir o acesso a um encfs mount para (a) processo (s) específico (s)?

Por padrão, o encfs é visível apenas para o usuário atual (exceto ao usar a opção --public ).

Executando o encfs, como outro usuário tem a desvantagem de estar propenso a problemas de permissão, pois os arquivos pertencerão ao outro usuário, possivelmente com permissões restritivas. Não quero lidar com problemas de permissão.

Por isso, quero executar o encfs pelo mesmo usuário, e a restrição de acesso por processo é tratada, por exemplo, grupos de controle (cgroups) ou namespaces.

    
por KrisWebDev 06.03.2016 / 00:51

1 resposta

2

As soluções abaixo usam namespaces por meio do comando unshare . Processos em outros namespaces não verão a montagem.

Não podemos usar unshare -r porque ele é executado com nogroups group, que o encfs / fuse não gosta.

Solução 1 (solicitará os direitos de root em todos os lançamentos)

Estamos usando sudo unshare para criar a montagem de ligação e marcá-la como privada. Uma vez feito isso, nós mudamos o usuário para sudo chamador ( sudo -u "#$SUDO_UID" -g "#$SUDO_GID" ) e removemos explicitamente os direitos de root ( sudo -K ). Nesse ponto, podemos chamar encfs e começar a fazer coisas com your_program_here . Quando finalizada, a montagem de ligação privada é excluída pela raiz raiz pai (portanto, sem perguntar novamente pela senha raiz do usuário), portanto, não fica mais visível pelo usuário root através de mount -l .

enc_dir="/path/to/enc_dir"
mount_point="/path/to/plain_dir"
RUN_CMD="mount --bind \"$mount_point\" \"$mount_point\"; \
         mount --make-private \"$mount_point\"; \
         sudo -u \"#\$SUDO_UID\" -g \"#\$SUDO_GID\" \
             bash -c \"sudo -K; \
                       encfs \\"$enc_dir\\" \\"$mount_point\\"; \
                       your_program_here \\"\\$@\\"; \
                       fusermount -u -z \\"$mount_point\\" \
                     \" - \"\$@\"; \
        umount \"$mount_point\""
sudo unshare -m bash -c "$RUN_CMD" - "optional" "arguments"

your_program_here pode ser o que você quiser, por ex. bash para um prompt de comando. Você pode passar argumentos para este programa ($ 1="opcional" $ 2="argumentos") corretamente.

Fonte: Lançar um comando sudoed após o término do script? responda por Celada + veja a solução de fontes 2.

Solução 2 (tem vulnerabilidade crítica ao usar compartilhamento não compartilhado > = v2.27.1)

Para evitar que unshare seja executado como root, precisamos usar o bit setuid nele.

sudo groupadd unshare
sudo adduser $USER unshare
sudo chmod u+s /usr/bin/unshare
sudo chown root:unshare /usr/bin/unshare

Aviso : isso provoca uma vulnerabilidade em versões recentes de compartilhamento não compartilhado (desde v2.27.1 ) e não deve ser usado, pois não compartilha mais os direitos de root ao executar o comando, para que qualquer pessoa possa ter acesso root. Uma solução alternativa existe e é descrita aqui .

Então (possivelmente um novo terminal é necessário):

unshare -m

Agora, devemos ter um shell com $ user sign, não # root sign. Agora, precisamos especificar explicitamente private ou rprivate nas opções de montagem (explicação nas fontes abaixo) e depois iniciar o encfs.

enc_dir="/path/to/enc_dir"
mount_point="/path/to/plain_dir"
sudo mount --bind "$mount_point" "$mount_point"
sudo mount --make-private "$mount_point"
encfs "$enc_dir" "$mount_point"

Os processos iniciados neste shell poderão visualizar o ponto de montagem. Outros processos não.

Fonte: Escondendo uma pasta criptografada em um sistema compartilhado sem acesso root (unshare -m) , comentado por Philipp Wendler & Não é possível obter namespaces de montagem por processo para funcionar responder por ub1quit33

Solução 3? (melhor da raça)

Avenidas a serem mais exploradas: Provavelmente há algo a ser feito colocando o script da Solução 1 em um arquivo .sh e definindo setuid bit + chown como na Solução 2.% variáveis#$SUDO_*ID podem precisar ser substituídas por outra coisa e sudo -K efetividade precisa ser testada.

Além disso, as variáveis enc_dir e mount_point não devem ser parametrizáveis, pois não são usadas com segurança. Caso contrário, eles devem ser escapados, ou melhor, eles devem ser passados como primeiros parâmetros sem compartilhamento (portanto $ @ deve ser substituído pelo intervalo de parâmetros posicionais $ {@: 2}).

Ou preencha uma solicitação de recurso para suporte a encfs / fusíveis em unshare -r para não compartilhar desenvolvedores ...

    
por 06.03.2016 / 00:51

Tags