Como reforçar o su com o dpkg-statoverride?

Question

Estou lendo um guia de fortalecimento do Ubuntu 14 e esta é uma das sugestões:

It generally seems like a sensible idea to make sure that only users in the sudo group are able to run the su command in order to act as (or become) root:

dpkg-statoverride --update --add root sudo 4750
/bin/su

Pesquisei o comando dpkg-statoverride , mas ainda não consigo descobrir exatamente o que o comando acima está fazendo?

Parece implicar que o Ubuntu 14, por padrão, permite que qualquer um sudo. Para testar, criei um novo usuário, logado como aquele usuário, tentei sudo e ele falhou - o que é bom.

Então, qual é o propósito da sugestão acima?

    

Answer 1

O objetivo é impedir que usuários comuns executem o comando su (su é semelhante a sudo, a diferença é que sudo executa um comando, su inicia uma nova sessão como um novo usuário, que dura até que o usuário execute exit)

O modo padrão de su é 4755 ou rwsr-xr-x, o "s" significa que o comando é set-UID (o que significa que ele sempre é executado como o usuário que o possui, em vez do usuário que acontece execute. Nesse caso, su é de propriedade de root, portanto, ele sempre é executado com privilégios de root)

O

su tem suas próprias medidas de segurança para garantir que o usuário que o executa tenha autoridade para se tornar outro usuário (normalmente solicitando a senha do outro usuário), mas é concebível que haja uma vulnerabilidade de segurança no su que permitir que um atacante de alguma forma o convença a fazer outra coisa sem autoridade.

Ao alterar o modo para 4750, ele impede que usuários comuns (usuários que não sejam root e aqueles no grupo sudo) leiam ou executem o mesmo, para que um invasor precise alterar a propriedade desse arquivo ou altere o modo do arquivo ou mude seu próprio UID / GID efetivo antes que eles possam tentar explorar essa vulnerabilidade teórica no su.

O comando dpkg-statoverride é útil nesta instância porque ele direciona o gerenciador de pacotes a usar esses valores de propriedade / modo para esse arquivo, mesmo que ele seja substituído por uma versão mais nova (por exemplo, via apt upgrade). Em outras palavras, isso torna mais permanente do que apenas um chown e um chmod.

Aqui está uma tática de propósito geral que eu recomendo para esta instância: Sempre que estou ajustando a configuração do su / sudo ou qualquer componente de autenticação em uma máquina Linux / UNIX, abro outra sessão ssh / putty para esse servidor e efetuo login como o usuário root e deixo essa sessão aberta em outra janela. Dessa forma, se eu estragar alguma coisa e me trancar, já tenho uma sessão de login onde posso consertar qualquer coisa que eu quebrei.

    

Answer 2

Dependendo de seus usuários, pode ser uma boa ou uma má idéia.

O comando su pode ser usado por usuários comuns para fazer login em qualquer outra conta, não apenas no superusuário, desde que eles saibam a senha da conta.

Isto é útil, e. quando dois usuários estão cooperando em um projeto, um deles (userA) está logado e eles precisam ler um arquivo acessível apenas ao outro usuário (userB). Simplesmente rodando

su -c 'cat /home/userB/file' userB >file

pode ser usado para copiar o arquivo para o diretório pessoal do usuário logado, mas isso só é possível se o usuário A tiver permissão para executar o comando su .

Em servidores de banco de dados PostgreSQL, geralmente é possível que os administradores de banco de dados alternem para o usuário postgres para executar algumas tarefas de manutenção que não são possíveis enquanto o servidor de banco de dados estiver ativo; para que isso funcione, eles precisam executar su - postgres .

As mesmas considerações se aplicam ao comando sudo (que é diferente e muito mais complexo que su - é apenas a configuração padrão que torna o comando útil principalmente para o grupo sudoers , porque esse grupo é permissão para executar qualquer comando como root No entanto, se você adicionar regras personalizadas, por exemplo, permitindo que qualquer usuário execute updatedb sem argumentos, os usuários fora do grupo sudoers precisarão de permissão de execução em sudo .

Além disso, não há apenas su que é setuid - também existe

• sg (permite entrar temporariamente em um grupo se houver uma senha de grupo definida)
• passwd (permite alterar a senha)
• chfn (permite alterar as informações do usuário)
• chsh (permite alterar o shell padrão)

e vários outros. Essas ferramentas compartilham muitos códigos com o comando su , então mudar o modo /bin/su não vai te comprar muito, e mudar o modo de todos eles certamente irá irritar seus usuários, especialmente no caso de passwd .

    

Answer 3

Em um servidor protegido, você precisa de alguns binários setuid / setgid, especialmente aqueles que podem ser executados por uma conta de usuário que não precise da ferramenta específica, por um motivo simples:

Você não confia totalmente nessas ferramentas para policiar o que alguém faz com elas. Bugs em tais programas ou suas dependências que permitiram aos usuários burlar esse policiamento são frequentemente encontrados e procurados ativamente por pesquisadores e atacantes de segurança. Configuração incorreta (o comportamento su depende da configuração da biblioteca PAM) pode causar o mesmo problema. Portanto, cada binário setuid / setgid que uma determinada conta (serviço ou usuário) pode executar é um vetor potencial para obter acesso root indesejado.

Embora problemas conhecidos em tais softwares geralmente causem atualizações / atualizações a serem disponibilizadas rapidamente, ser forçado a instalá-los rapidamente pode causar interrupções - e alguns buracos podem não ser conhecidos de todos, incluindo o fornecedor.

Para minimizar a chance de um problema urgente ser resolvido, faz sentido fazer algo como link , em seguida, pesquise quais destes podem ser eliminados (a maioria deles se você estiver executando um servidor construído propositadamente e souber o que está fazendo), preferencialmente usando métodos como o dpkg-statoverride que o seu sistemas de gerenciamento de pacotes suportam para manter tais mudanças permanentes.

Há outra razão para restringir o acesso ao "su" em configurações específicas com o NFS old school - você pode, por razões essencialmente políticas, restringir a conta root (que alguns usuários podem obter, novamente, razões políticas. ) de usar su trivialmente, pois contorna o sinalizador root_squash de uma montagem NFS.