Acho que você deveria repensar seu problema. Eu não sei de nenhuma maneira de conseguir o que você quer, mas ... se você tem um usuário com sudo com todos os privilégios que você não confia completamente, então você deve restringir os privilégios.
No Linux, autenticamos usuários contra o AD. Os usuários do AD não estão listados em / etc / passwd.
Estamos prestes a implantar uma solução NFS para montar um espaço extra para cada grupo de usuários.
Se um usuário (A) com privilégios sudo sues for root, ele poderá representar o usuário (B) apenas pelo su (B) e acessando o NFS.
Existe alguma maneira de não permitir root ao su user se o usuário não estiver listado em / etc / passwd?
Se você vai dar privilégios de root ao User A, então não, você não pode impedi-los de fazer qualquer coisa (não importa que blocos você tenha colocado, o root sempre pode contorná-los; com pouquíssimas exceções). Você deve adicionar o Usuário A aos sudoers e configurar bem os programas que eles podem ou não executar.
Não responde à sua pergunta direta, mas acho que seu problema é com o NFS, não o sudo / su - você terá esse problema sempre que usar o NFSv3, pois ele depende dos UIDs para impor permissões de acesso.
Mesmo que você de alguma forma evitasse que os usuários mudassem para o root e voltassem para outro UID, um usuário mal-intencionado poderia simplesmente conectar seu próprio dispositivo ou inicializar um sistema operacional diferente em seu sistema especialmente configurado e superar a proteção.
Já pensou em usar o NFSv4? Ele usa o Kerberos para autenticar solicitações de montagem e impor permissões de acesso, portanto, não estaria vulnerável a isso.
Tags sudo security nfs impersonation