Eu queria saber hoje se havia uma maneira de impor um usuário não raiz para ter um arquivo authorized_keys específico (entre outros arquivos sensíveis). Eu criei esta solução.
StrictModes em sshd_config (conseguiu manobrar com propriedade de arquivo e outras coisas, e sshd com StrictModes ativo é muito exigente) Evite que o usuário exclua arquivos que não sejam de sua propriedade em seu diretório pessoal com o adesivo:
chown root:user /home/user chmod 1770 /home/user Todos os arquivos e diretórios que não devem ser modificados / removidos devem passar por isso:
chown root:user file_or_folder chmod 0640 file_or_folder chmod g+x folder Até agora, esta abordagem parece funcionar. O usuário não pode modificar / excluir os arquivos, e não há risco de que o usuário deixe sua própria pasta pessoal legível / gravável ( isso parece seja a razão por trás de StrictModes ) porque ele não possui seu diretório home.
A pergunta é: estou faltando alguma coisa? Isso pode ser contornado? Existem desvantagens?
Parece bom, mas no linux provavelmente há sempre alguma maneira de contornar isso, porque uma vez que você tenha uma conta, escalonando seu priv. é muito mais fácil do que invadir, se você não confia em seus usuários. Se você está realmente preocupado, eu sugeriria algum tipo de shell restrito ou limitado. Estes também não são à prova de hackers, mas tendem a ajudar na maioria dos casos.
Você pode tornar um pouco mais difícil para o usuário usar o arquivo chattr + i para torná-lo imutável.
Eu deixaria o StrictModes ativado. O objetivo é dificultar que outra pessoa substitua o arquivo AuthorizedKeys de um usuário. Você pode ter protegido esse usuário, mas todos os outros usuários estão vulneráveis.
Há uma variedade de ferramentas que podem ser usadas para restabelecer uma configuração sensata se ela for quebrada. Eu tenho usado cfengine . puppet é uma alternativa popular. Mesmo se o usuário alterar suas configurações, a ferramenta redefinirá a configuração de volta a um estado sã. Se desejar, pode alertar que a mudança foi necessária.
De seus requisitos, parece que você está protegendo uma conta para um serviço. Normalmente, essas contas não teriam uma senha e nem uma conta de usuário normal. Esse tipo de requisito para uma conta de usuário normal aumentaria meus problemas de segurança. Como usuário, eu não aceitaria esse tipo de restrição na minha conta. Como administrador, eu ficaria preocupado com o fato de a conta estar sendo usada para propósitos com dois perfis de segurança diferentes.