RESTRINGIDO
A forma como eu interpreto "restringir usuários ao conjunto de programas que não [permitem escudos de shell] é muitas vezes impraticável", significa que é tão comum para programas que, aparentemente, parecem executar um único e seguro tarefa, mas na verdade permite que se execute qualquer outro programa, que se deve assumir, no caso geral, que dar um acesso de usuário a um único comando permitirá que eles executem qualquer comando que desejarem.
O exemplo típico é talvez editores de texto: além de permitir que o usuário abra qualquer arquivo de dentro do editor, não apenas o arquivo que foi dado na linha de comando, editores populares permitem que você inicie um shell completo.
O mecanismo sudoedit fornece um editor que é restrito a editar apenas um arquivo específico (dando ao usuário uma cópia do arquivo a ser editado, permitindo que ele edite-o como a si mesmo, somente após atualizar o arquivo privilegiado). Se alguém usasse o RESTRICT para permitir que um usuário executasse, digamos, o emacs, em um arquivo específico, esse usuário, de dentro do editor do emacs rodando como um usuário privilegiado, poderia de fato editar qualquer arquivo acessível àquele usuário e iniciar um shell. como esse usuário.
NOEXEC
Quando um programa é iniciado dessa maneira, suas bibliotecas dinâmicas normais são substituídas para proibir a geração de um novo shell. Isso deve fazer com que tentar iniciar um comando shell a partir de, digamos, less falhe, desde que less seja um executável dinâmico. No caso de alguém querer permitir a edição de um arquivo específico, é provavelmente mais seguro e mais agradável para o usuário usar o sudoedit (porque eles têm acesso às configurações personalizadas do seu próprio editor).
Para verificar se o NOEXEC funcionará no seu sistema, presumo que ele esteja em qualquer sistema operacional listado na documentação, desde que o programa de destino esteja realmente vinculado dinamicamente. Mas é melhor verificar à mão, como a documentação sugere.