A segurança é sempre sobre fazer concessões. Assim como o servidor proverbial que está em um local seguro, desconectado, no fundo do oceano, root seria mais seguro se não houvesse nenhuma maneira de acessá-lo.
Os ataques LD_PRELOAD e PATH, como aqueles que você descreve, supõem que já existe um invasor com acesso à sua conta ou, pelo menos, aos seus dotfiles. O Sudo não protege muito bem disso - se eles têm sua senha, afinal, não é necessário tentar enganá-lo para mais tarde ... eles podem usar apenas sudo agora .
É importante considerar o que o Sudo foi projetado originalmente: delegação de comandos específicos (como aqueles para gerenciar impressoras) para "sub-administradores" (talvez alunos de graduação em um laboratório) sem dar raiz completamente. Usar o sudo para fazer tudo é o uso mais comum que vejo agora, mas não é necessariamente o problema que o programa deveria resolver (daí a sintaxe de arquivo de configuração ridiculamente complicada).
Mas, sudo-for-root irrestrito faz resolver outro problema de segurança: gerenciamento de senhas de raiz. Em muitas organizações, elas tendem a ser passadas como doces, escritas em quadros brancos e deixadas para sempre. Isso deixa uma grande vulnerabilidade, já que revogar ou alterar o acesso torna-se um grande número de produção. Mesmo manter o controle de qual máquina tem qual senha é um desafio - e muito menos rastrear quem sabe qual delas.
Lembre-se de que a maioria dos "crimes cibernéticos" vem de dentro. Com a situação da senha de root descrita, é difícil rastrear quem fez o quê - algo que o sudo com o log remoto lida muito bem.
No seu sistema em casa, acho que é mais uma questão da conveniência de não precisar lembrar de duas senhas. É provável que muitas pessoas estivessem simplesmente configurando-as para serem as mesmas - ou pior, configurando-as para serem as mesmas inicialmente e depois deixando-as fora de sincronia, deixando a senha de root para apodrecer.
Usar senhas em tudo para SSH é perigoso, já que os daemons ssh trojan com senhas de sniffing são colocados em algo em algo como 90% dos comprometimentos de sistemas do mundo real que eu vi. É muito melhor usar chaves SSH, e isso também pode ser um sistema viável para acesso remoto à raiz.
Mas o problema agora é que você mudou do gerenciamento de senhas para o gerenciamento de chaves, e as chaves ssh não são muito gerenciáveis. Não há como restringir cópias, e se alguém fizer uma cópia, terá todas as tentativas que deseja para forçar a frase secreta. Você pode fazer uma política dizendo que as chaves devem ser armazenadas em dispositivos removíveis e montadas somente quando necessário, mas não há como aplicá-las - e agora você introduziu a possibilidade de um dispositivo removível ser perdido ou roubado.
A maior segurança será obtida através de chaves únicas ou tokens criptográficos baseados em tempo / contador. Isso pode ser feito em software, mas o hardware resistente a violações é ainda melhor. No mundo do código aberto, há WiKiD , YubiKey , ou LinOTP e, claro, há também o peso pesado proprietário RSA SecurID . Se você está em uma organização de médio a grande porte, ou mesmo em uma organização pequena preocupada com a segurança, recomendo enfaticamente que você analise uma dessas abordagens para acesso administrativo.
É provavelmente um exagero para o lar, no entanto, onde você não tem os problemas de gerenciamento, desde que siga práticas de segurança sensatas.