Como o OpenSSH sftp jail / chroot está funcionando?

Question

Esta pergunta é muito ampla ...

O que eu realmente quero saber é se ele realmente faz ou não chroots e, em caso afirmativo, como um usuário SSH deamon [1] pode ser lançado naquela cadeia apesar da óbvia falta do binário / lib necessário no chroot .

O Google está surpreendentemente silencioso sobre o assunto. Mas uma boa referência para explicar isso é o suficiente (no entanto, eu não sou o suficiente para ler e entender seu C).

[1]: Eu estou falando sobre o daemon transiente real com privilégios de usuário que é iniciado na conexão pelo daemon principal do OpenSSH raiz.

    

Answer 1

A outra resposta é bem vaga (também a questão é), então tentarei ser mais detalhado sobre esse fenómeno. Eu sei que este tópico não é para todos, mas para esses interessados é uma coisa muito boa de se conhecer.

Existem dois lugares diferentes onde o chroot é feito e você está cutucando os dois, então tentarei alinhar suas idéias:

1. Existe separação de privilégios , que é um mecanismo de segurança e parte dele também é chroot como uma limitação de criança de rede. Isso geralmente é um diretório vazio, como /var/empty .

   A razão é que em poucas palavras, se houver alguma vulnerabilidade, provavelmente não será explorável, porque esse processo não vê o sistema de arquivos e também é limitado de outras maneiras (sandbox, SECCOMP palavras-chave para leituras posteriores).

2. Mais tarde, você poderá chroot da sessão do usuário (não apenas SFTP) em um diretório específico para impedir o acesso a todo o sistema de arquivos. Esta é provavelmente a parte em que você está interessado, com base no título.

   A magia sobre o sftp no chroot é que você pode especificar Subsystem sftp internal-sftp (em vez do caminho completo Subsystem sftp /usr/lib/openssh/sftp-server ). Isto implica que sshd tem todo sftp-server compilado e em vez de exec no binário, apenas chama a função onde o comportamento do servidor é definido. Isso não requer nenhum arquivo de suporte em chroot para o usuário (ao contrário da sessão normal, em que você precisa do shell e de seus objetos compartilhados dependentes). Você também pode exigir o registro de soquete, se você estiver interessado em tais informações.

Answer 2

Eu tenho tentado lidar com o modo de operação de separação de privilégios, para acrescentar algum log extra ao ssh chamado com comandos para o servidor remoto. Como você diz, você não encontra muita coisa sobre isso.

A chave óbvia é a opção "UsePrivilegeSeparation".

No processo de autenticação do usuário, um fork sshd descarta os privilégios e é executado em um chroot usando o usuário sshd. Analisando o código fonte, achei chroots em / var / empty.

Ele também tem algumas verificações que algumas operações precisam combinar entre o código antes e depois do chroot, que eu ainda não explorei.

Vou deixar também um link relevante:

link