Como proteger usuários do sistema que só executam processos de aplicativos?

Question

Eu criei um usuário do sistema através do comando adduser para uso em um aplicativo que eu instalei. Este usuário deve executar processos específicos do aplicativo e tal (pense no usuário do sistema postgres não fazendo nada além de executar coisas relacionadas ao postgres)

Como esse usuário não faz nada além dos lances do aplicativo, existe uma maneira de impedir que um ser humano faça login com esse usuário? Este usuário não faz parte de nenhum grupo (então não preciso se preocupar com logins do ssh ou outros grupos permanentes). Eu li que não ter uma pasta home ajudará a impedir logins, mas eu precisava de uma pasta base para este usuário, porque é onde eu compilei / instalei o aplicativo.

Além de impedir que um ser humano faça login nesta conta de usuário, há outras considerações de segurança a serem consideradas?

    

Answer 1

Há duas coisas que você deve fazer para evitar que as pessoas usem essa conta de usuário como uma "conta de usuário humana real".

Como ninguém precisa fazer login como conta para nenhuma finalidade, a primeira e mais importante coisa a fazer é garantir que a autenticação de senha nunca seja bem-sucedida. A excelente resposta do guntbert explica isso em detalhes. Em resumo, você pode executar:

sudo passwd -l user

Separadamente, também é uma boa idéia configurar o login shell do usuário para algo que não executa nenhuma operação e sai imediatamente:

sudo chsh -s /bin/false user

Dessa forma:

• Efetuando login como o usuário usando um mecanismo diferente da autenticação por senha (como autenticação baseada em chave) para obter um shell normalmente falhará. No entanto, ainda pode ser possível que algumas funcionalidades relacionadas ao SSH funcionem.

  Por exemplo, se a autenticação baseada em chave estiver habilitada para o usuário, alguém ainda poderá usá-la para autenticar e abrir uma conexão SSH para scp ou sftp ou para criar um túnel criptografado e possivelmente acessar outras funcionalidades.

• As tentativas de simular um shell de login normalmente falharão. No entanto, alguém que possa executar programas como root ou que tenha alguma forma não baseada em senha para autenticar como o usuário ainda pode executar um shell de não-login, que fornece os mesmos recursos que um shell de login.

  Por exemplo, a configuração do shell de user como /bin/false impedirá que su - user e sudo -i -u user (entre outros) funcionem, mesmo que seja executado como root . Mas eles não impedirão que su user , sudo -s -u user ou sudo -u user bash (entre outros) trabalhem quando forem executados como root .

Evidentemente, desabilitar o shell de login de um usuário que já não pode efetuar login por meio de autenticação de senha e que ainda não tem autenticação baseada em chave configurada não confere um grande benefício de segurança . Então, por que isso? Porque:

• É possível ajudar a lembrar os usuários que fazem poderes de administrador para pensar duas vezes antes de fazer login (ou simular um login) como user .

• Definir o shell de um usuário como algo não funcional é uma maneira conveniente e geralmente eficaz de mostrar a qualquer pessoa que esteja lendo /etc/passwd que o usuário não representa um ser humano e não deve ser representado de forma interativa.

  (No Ubuntu e em outros sistemas modernos semelhantes ao Unix /etc/passwd armazena informações de conta, mas não os hashes de senha reais - os que estão em /etc/shadow . /etc/passwd podem ser visualizados por todos ou a maioria dos usuários humanos no sistema, incluindo não administradores.)

• Se, por algum motivo, a autenticação por senha for reativada para o usuário, o shell de login do usuário não sendo funcional normalmente proporcionará um benefício de segurança substancial.

Answer 2

Você só precisa bloquear a conta para que nenhuma senha válida possa ser inserida:

sudo passwd -l username

Agora, faça login nesta conta com uma senha desativada, mas faça login por meio de su (de um processo em execução com permissões root (como sudo -i )) ou ssh-keys (que você provavelmente não habilitado) ainda seria possível. Não recomendo desabilitar a conta completamente porque os programas para os quais você precisa não puderam ser executados.

Você pode realizar quase o mesmo editando /etc/shadow com o comando sudo vipw -s ( vipw bloqueia o arquivo para evitar danos e chama seu editor CLI favorito) e substituindo a sequência após os primeiros dois pontos com ! .

 mysysuser:!:15819:0:99999:7:::

Se você pegar a segunda rota, é recomendável fazer o backup de /etc/shadow (no caso de um erro). Uma maneira é sudo cp /etc/shadow /etc/shadow.old . Depois que a nova configuração funcionar, remova o backup ( sudo rm /etc/shadow.old ), pois pode ser considerado ruim ter cópias extras desnecessárias de usuários hashes de senha por aí (uma vez que uma senha é alterada, o hash deve desaparecer, então hashes antigos não podem ser quebrados para obter acesso a outros sistemas onde senhas antigas ainda podem ser definidas).