Os administradores do sistema geralmente precisam conceder permissões avançadas aos usuários para que eles possam executar tarefas privilegiadas. A ideia de que os membros da equipe tenham acesso a um sistema FreeBSD para executar suas tarefas específicas abre desafios únicos para cada administrador. Esses membros da equipe precisam apenas de um subconjunto de acesso além dos níveis normais de usuário final; no entanto, eles quase sempre dizem ao gerenciadores que eles são incapazes de executar suas tarefas sem acesso de superusuário. Felizmente, não há motivo para fornecer tal acesso aos usuários finais porque existem ferramentas para gerenciar esse exato requisito.
Até este ponto, o capítulo de segurança cobriu o acesso a usuários autorizados e a tentativa de impedir o acesso não autorizado. Outro problema surge quando os usuários autorizados têm acesso aos recursos do sistema. Em muitos casos, alguns usuários podem precisar acessar os scripts de inicialização do aplicativo ou uma equipe de administradores precisa manter o sistema. Tradicionalmente, os usuários e grupos padrão, as permissões de arquivo e até mesmo o comando su() gerenciariam esse acesso. E como os aplicativos exigiam mais acesso, à medida que mais usuários precisavam usar recursos do sistema, era necessária uma solução melhor. A aplicação mais usada atualmente é o Sudo.
O Sudo permite que os administradores configurem um acesso mais rígido aos comandos do sistema e forneçam alguns recursos avançados de log. Como uma ferramenta, ele está disponível na coleção de ports como security/sudo ou usando o utilitário pkg(8). Para usar a ferramenta pkg(8):
#
pkg install sudo
Após a conclusão da instalação, o visudo
instalado abrirá o arquivo de configuração com um editor de texto. O uso do visudo
é altamente recomendado, pois vem com um verificador de sintaxe incorporado para verificar se não há erros antes que o arquivo seja salvo.
O arquivo de configuração é composto de várias seções pequenas que permitem uma configuração extensiva. No exemplo a seguir, o mantenedor do aplicativo da web, user1, precisa iniciar, parar e reiniciar o aplicativo da web conhecido como webservice
. Para conceder a este usuário permissão para executar estas tarefas, adicione esta linha ao final do arquivo /usr/local/etc/sudoers
:
user1 ALL=(ALL) /usr/sbin/service webservice *
O usuário pode agora iniciar o webservice
usando este comando:
%
sudo /usr/sbin/service
webservice
start
Embora essa configuração permita que um único usuário acesse o serviço webservice; No entanto, na maioria das organizações, existe uma equipe inteira da Web encarregada de gerenciar o serviço. Uma única linha também pode dar acesso a um grupo inteiro. Essas etapas criarão um grupo da Web, adicionarão um usuário a esse grupo e permitirão que todos os membros do grupo gerenciem o serviço:
#
pw groupadd -g 6001 -n webteam
Usando o mesmo comando pw(8), o usuário é adicionado ao grupo webteam:
#
pw groupmod -m user1 -n webteam
Finalmente, esta linha no arquivo /usr/local/etc/sudoers
permite que qualquer membro do grupo webteam gerencie o webservice
:
%webteam ALL=(ALL) /usr/sbin/service webservice *
Ao contrário do su(1), o Sudo requer apenas a senha do usuário final. Isso adiciona uma vantagem em que os usuários não precisarão de senhas compartilhadas, uma descoberta na maioria das auditorias de segurança e o que por si só já ruins em todos os aspectos.
Os usuários autorizados a executar aplicativos com o Sudo só inserem suas próprias senhas. Isso é mais seguro e oferece melhor controle do que o su(1), onde a senha de root
é inserida e o usuário adquire todas as permissões de root
.
A maioria das organizações está se movendo ou migrou para um modelo de autenticação de dois fatores. Nestes casos, o usuário pode não ter uma senha para entrar. O Sudo resolve estes casos com a variável NOPASSWD
. Adicioná-lo à configuração acima permitirá que todos os membros do grupo webteam
gerenciem o serviço sem o requisito de senha:
%webteam ALL=(ALL) NOPASSWD: /usr/sbin/service webservice *
Uma vantagem para implementar o Sudo é a capacidade de ativar o log de sessão. Usando os mecanismos de log integrados e o comando sudoreplay incluído, todos os comandos iniciados por meio de Sudo são registrados para verificação posterior. Para ativar esse recurso, adicione uma entrada de diretório de log padrão, este exemplo usa uma variável de usuário. Existem várias outras convenções de nome de arquivo de log, consulte a página de manual do sudoreplay para obter informações adicionais.
Defaults iolog_dir=/var/log/sudo-io/%{user}
Este diretório será criado automaticamente após o logging ser configurado. É melhor deixar o sistema criar o diretório com permissões padrão apenas para estar seguro. Além disso, essa entrada também registra os administradores que usam o comando sudoreplay. Para alterar esse comportamento, leia e descomente as opções de log dentro do arquivo sudoers
.
Uma vez que esta diretiva tenha sido adicionada ao arquivo sudoers
, qualquer configuração de usuário pode ser atualizada com a solicitação para acessar o log. No exemplo mostrado, a entrada webteam
atualizada teria as seguintes alterações adicionais:
%webteam ALL=(ALL) NOPASSWD: LOG_INPUT: LOG_OUTPUT: /usr/sbin/service webservice *
Deste ponto em diante, todos os membros do grupo webteam
que alteram o status do aplicativo webservice
serão registrados. A lista de sessões anteriores e atuais pode ser exibida com:
#
sudoreplay -l
Na saída, para reproduzir uma sessão específica, procure a entrada TSID=
e passe-a para o sudoreplay sem outras opções para reproduzir a sessão na velocidade normal. Por exemplo:
#
sudoreplay user1/00/00/02
Enquanto as sessões são registradas, qualquer administrador pode remover as sessões e deixar apenas uma questão de por que elas fizeram isso. Vale a pena adicionar uma verificação diária por meio de um sistema de detecção de intrusão (IDS) ou software semelhante para que outros administradores sejam alertados sobre alterações manuais.
O sudoreplay
é extremamente extensível. Consulte a documentação para mais informações.
All FreeBSD documents are available for download at https://download.freebsd.org/ftp/doc/
Questions that are not answered by the
documentation may be
sent to <freebsd-questions@FreeBSD.org>.
Send questions about this document to <freebsd-doc@FreeBSD.org>.