Sempre foi minha ideologia que, como usuário, você possa fazer o que quiser no Linux e para todo o resto, sempre existe sudo. sudopermite executar poucas coisas como outros usuários, na maioria dos casos como rootpara administração do sistema. sudotem sido um recurso de maior vantagem delegar algumas das minhas tarefas e privilégios de rotina como usuário (raiz) a outros e ajudar a gerenciar melhor meu tempo e outros sem elevar os privilégios para além do necessário. Ao mesmo tempo, é minha confiança neles que mantém suas entradas presentes nosudoersarquivo de configuração. Não tenho certeza se isso pode estar relacionado, mas o que posso dizer é que, o sudo oferece uma melhor perspectiva de segurança de quem tudo e o que eles podem fazer com seus privilégios confiáveis. Mesmo que algo dê errado, eles permanecem responsáveis. (Eu sempre posso fazer algumas coisas furtivas com informações de log de sudoers para encontrar os culpados também). Meus funcionários sempre expressaram sua preocupação comigo por terem que digitar sudo para tudo o que queriam fazer com privilégios elevados no ambiente Linux. Aqui também encontrei a mesma pergunta.
Para ver as soluções e minha busca para encontrar as alternativas, me deparei com Controles de Acesso Baseado em Recursos,RBAC mas em uma outra aventura Solariscom ferramentas como pfexecetc. Essa abordagem é mais melhor porque isso manteria os privilégios dos usuários já elevados e confiaria na consciência e atenção do que os administradores de sistemas gostariam de fazer com seus privilégios.
Considerando as soluções disponíveis do RBAC e suas implementações no mundo Linux, me deparei com
SELinux http://www.ibm.com/developerworks/linux/library/l-rbac-selinux/
grsecurity http://en.wikipedia.org/wiki/Grsecurity
e, embora existam outras implementações, eu as consideraria na ordem superior da lista. A implementação do RBAC é muito trabalhosa em uma organização, especialmente quando há muitos usuários. O RBAC soaria uma solução maior em ambientes homogêneos. No entanto, quando existem instalações heterogêneas do Unix na rede e o banco de dados do usuário é comum, isso talvez falhe. Como o SELinux não é escalável / implementado no Solaris, as ferramentas RBAC / pfexec não são implementadas no Linux. Existem abordagens diferentes para fazer uma única coisa. Por exemplo: http://blogs.oracle.com/darren/entry/opensolaris_rbac_vs_sudo_howto
Instalações diferentes em toda a rede podem não suportar essa abordagem (no entanto, o openrbac pode ser considerado uma abordagem de implementação comum), pois o sudoers é uma abordagem de host único ou não é capaz de configuração centralizada na rede / domínio./etc/sudoersprecisa ser sincronizado sempre que houver uma alteração. No entanto, há um requisito de base de conhecimento ao operar o arquivo sudoers, é necessário entender o idioma da política da configuração do sudoers para não cometer erros e permitir concessões. O RBAC pode oferecer uma abordagem centralizada até certo ponto, enquanto os perfis de segurança podem ser comuns, adicionar / remover um usuário da função concedida pode ser feito em um único local (que é o local onde as informações do usuário / senha / grupo são armazenadas para o domínio como LDAP, NIS ou AD). Isso também implicitamente exigiria a compreensão dos comandos necessários para operar no banco de dados RBAC, como smexec, smmultiuser, sendo poucos.
O Sudo pode oferecer uma abordagem mais multiplataforma aqui, ainda que funcione em todas as plataformas similares ao Unix, que oferecem os recursos setuid. Ambos são bem sudo- RBACsucedidos em conceder aos usuários não-root alguns privilégios que podem ser feitos sem fornecer a rootsenha em si. O Sudo pode oferecer uma abordagem mais refinada / granular nos argumentos da linha de comando que podem ser usados durante a execução dos comandos e restringir-se exclusivamente a qual comando com argumentos pode ser executado com privilégios elevados. Embora o RBAC possa restringir o uso até os comandos ou binários instalados, mas não tem controle sobre os argumentos da linha de comando. A auditoria é muito melhor e integrada ao ambiente RBAC, enquantosudo, depende da configuração e também das restrições de segurança adotadas (como não conceder o shell e, em particular, os hosts podem fazer login nos outros hosts sem problemas). Essas são apenas algumas das diferenças que eu poderia citar e, pessoalmente, tenho uma tendência a usar o sudo que o RBAC, embora com as limitações mencionadas eu possa vir a implementar algumas soluções alternativas. Até que todos os problemas sejam resolvidos pelo RBAC para melhor vantagem do sudo, não acho que o sudo vá embora, pois é simples.